Slimfish wrote:Hi again,
i see you post schematics in the hackers corner. That's great!
After inspectig the schematics a little, i realize that schematics version is 1.05 but RF-Explorer hardware is 1.04. Small version change.. but what are the differences?. Also, in the schematic does not appear the LCD model (controller). Which one is used?
There are no actual changes from v1.04 to v1.05 circuitry, except we will no longer include 8Mhz XTAL as we are not using it. All testing done with assembled final units shown no need for XTAL as the internal oscillator on PIC24 is accurate enough thanks to some advanced finetune techniques used in the firmware. So v1.04 includes a XTAL in the PCB but not actually used, so I published upcoming v1.05 circuit which is how it actually works.
There is another minor change on the MCLR pullup resistor, it was 56K in v1.04 and now is 22K, no real functional change.
LCD is based on a ST7565 chipset.
Slimfish wrote:Regarding to the Explorer, it's very nice and easy to use, but as i mentioned in the first message it's fisrt use for us will be for field testing. That involves working with Matlab for data processing, so we developed kind of a Matlab script which reads the data right from the Explorer (i plan to publish it when the code reach enough stability). But a few issues have arose:
1. Serial port speed: 2.4k/500k. No problem with the first value, but 500k it's not standard at all (most windows software is limited to 256k or even 115.2k). I understand that 500k is used to high speed firmware updating, but if you could add an intermediate speed (or change lower one) it would be very nice.
Good question. I suggest you to access our official support discussion group where some of these questions were discussed. Feel free to join https://groups.google.com/group/rf-explorer
There is a compromise between baudrate accuracy and speed. The CP2102 USB driver supports 500Kbps natively, and that is the highest speed you can get with enough tolerance out of a 8Mhz oscillator. Other baudrates such as 115Kbps, besides being way slower, will get out of 5% tolerance mandated by RS232. I can add some of these modes, but serial connection will break easily and would certainly frustrate users.
Most modern serial console software allows you to specify custom baud rate, the only real limitation in a capable application should be the USB serial driver.
I could add a 56Kbps which should be still within 5% tolerance and will work clearly faster than 2400bps for you, let me know if you want to test that option yourself in a beta firmware. It will probably be available in advanced mode only (i.e. you may need to start connection in 2400bps from your script then specify you want to switch to 56Kbps from a software command). But for practical purposes, I suggest you to contact Matlab to get an updated version supporting custom baud rate, it may be a better option for you long term.
Slimfish wrote:2. Related to the first point we noted that frames acquisition are dependent on port speed. For 2.4k we get 2 frames/s (more or less) and for 500k about ten. How is the sweep speed computed?
Please refer to this thread to understand how sweep speed works: https://groups.google.com/group/rf-expl ... e249d355af
On top of actual sweep speed, the serial communication will be a bottleneck at 2400bps. Note there are 112 samples per sweep, accounting for 8 data bits and 1 stop bit this is 112*9 bits = 1008 bits per sweep. At 2400bps you can barely get more than 2 sweeps per second, regardeless actual sweep capacity from the RF section.
Slimfish wrote:3. In the RF Explorer RS232 interface specs, Data Field List, AdBm is a binary byte. How is it interpreted? Is it the value read from module RSSI register (Figure 31 of the datasheet)?
Thank you in advance!!!
Almost. In current firmware v1.05 this is the raw RSSI value from Si4432 after a number of calibration steps are performed. The PC client software decodes that value properly and translate it to dBm with a 0.5dBm precission. Take a look on the source code to use the right formula, including proper offset range.
However, to properly support different chips and band ranges, upcoming firmware versions may change the value to a more normalized one so all frequency bands exhibits the same formula. This means the interface will not change, but the exact formula may change. PC Client will be updated accordingly based on this so advanced users can easily adapt any custom developed client software. The good news is upcoming firmware will use the same formula regardless the frequency band, something not feasible with the current approach.
BTW, in which band is your RFExplorer working?