Hi,
i’ve just received the RF-Explorer(s) (433MHz) and i’m eager to explore the circuits/firmware of RF-Explorer… 
will you provide some schematic and/or firmware source?
Thank you,
Slimfish
Hi Slimfish,
Welcome to the rf-explorer group and thank you for your interest.
I’m in the process of creating the “hacker’s corner” in www.rf-explorer.com, will probably have that fully available on Monday. It will include schematic, detailed PC serial interface, Windows PC source code, etc.
I will let you know as soon as I have it published.
Firmware is not open source as some of the internal libraries are not GPL compatible, but we are working on a fully programmable expansion module which will allow you to fully hack the unit in an Arduino compatible environment.
Best regards
Hi arocholl,
for some tests with the RF_Explorer i need a discrete emitter frequency change. It’s quite tedious to write the whole firmware from grounds up, that’s why i asked. If some of the routines (like FFT or others) are not available as GPL, i’ll also be delighted with a minimal system initialisation (LCD, RF module) subset.
Also, how long is the battery expected to last (in terms of usage time) in both emitter and receiver modes? One of the explorers has been already 10+ hour in reception and the battery indicator reports a little less than a half (which is a lot!). I don’t want to deplete (just in case of a bug in firmware) the li-ion battery. Most of my tests are in field, so it’s good to know how long would it last.
Thank you in advance!!!
Sure, please take a look on this => section for hackers.
I’m very open to do any specific customization you may need, if we feel like any addition is of common interest for others in the community. I do see a lot of value on a sweep emitter with configurable parameters, such as frequency steps and sweep time. Just tell me the details you need and we can work it out.
If you really want to program yourself, the best I can offer is a extension module for you to customize the unit reusing the original firmware by means of interfacing with it. By an elaborated RF Explorer interface (not yet specified but in our plans) you could handle the transmitter, the receiver and the LCD from the programmable extension module.
That is a good point, I neglected to properly document it in the user manual. It is in the to-do list for the very near term.
Basically the RF Explorer takes anywhere from 50mA to up to 250mA based on RX or TX mode, and LCD backlight mode. In the lowest consumption mode (RX with LCD off), you will get at least 14hs of continuous run. It is amazing how efficient the MCU and Transceivers are in modern chips. With LCD at max bright and TX in max power mode, you will get no more than 5hs, typically 3hs.
As a note of caution: lipo should never get fully depleted as the safety mechanism is analogic, not embedded in firmware. This put the system down when the lipo is about 3.2V, but that will still consumes a few milliamps and will damage the lipo if the unit is not powered off in a few hours more. In our experiments, having it running till battery was exhausted for more than 14hs was ok, but never got it ON for more than 20hs in a row, which I will consider as the safety margin.
I will document all this in detail in the user manual and will notify when available. In the meantime, consider 14hs as the max limit when all ideal conditions are met, but if you really need to have it working for more hours, I suggest to use an external USB compatible power source (either mains or battery based) so you can have it working forever.
Hi Arocholl,
thank you for your fast answer. The modifications in the emitter will be about frequency and power. Maybe the emitter frequency configuration can use the spectrum analyser center frequency or similar. Relative to the output power i would rather use dBm units instead of low/medium/high and have all the possible output levels (1,2,5,8,11,14,17,20).
I have a question about output power. In the Si4432 datasheet states that output power range is 1-20 dBm but in the documentation is 0-20 dBm. Which one is correct?
These two (frequency/power) are very useful to calibrate/characterize equipment. Also a single frequency amplitude logging will be very nice. A frequency sweep will be also very useful but maybe it’s more complicated to program.
Transmitted center frequency is already configurable in the transmitter menu. Do you mind to elaborate a bit more on what you find missing there so I can better understand?
In terms of power, we can certainly make it more granular, although I bet some users will find it too granular. I will look into a way to have both options available and will check with you.
Well, that is an interesting question 
. The answer is not that simple. If you look into the “data short”, it tells you it goes from 11-20dBm. Which is wrong. In the “data sheet”, they tells you 0-20dBm, which is also wrong but certainly closer to reality. The most accurate answer is on the AN440 Application Note, you will find there it actually goes (-1)-20dBm, which makes sense because every step is 3dBm. But of course all this depends on the tuning circuit, VSWR and insertion losses, and you need to account for a typical ±3dBm accuracy. Based on our tests in the specific circuitry used in RFExplorer with a 50Ohm load, you should expect 0-20dBm with ±3dBm deviation.
Thanks!
Hi arocholl,
maybe i explained myself very bad. I suggested that the frequency generator could make a simple (not single) frequency sweep based on the configuration of the spectrum analyzer. This way you don’t have to take in to account configurable sweep times/steps.
Thank you for considering non fuzzy output powers. Respecting to the Si4432 chip i also found the documentation a bit non coherent.
Thank you!!
I will work in a draft code in a few days and will discuss with you, once a beta version is available for testing so we can confirm the enhancement is what you are looking for.
Thanks
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?
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:
- 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.
- 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?
- 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!!!
Hi there,
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.
Good question. I suggest you to access our official support discussion group where some of these questions were discussed. Feel free to join groups.google.com/group/rf-explorer anytime.
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.
Please refer to this thread to understand how sweep speed works: 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.
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?
Best,
Ariel
Is your main use for this feature a RFExplorer connected to a PC or working standalone? If it is connected to a PC, we can start with a beta firmware interacting with a new RS232 command set rather than new menu options. This may give you more flexibility.
Cheers,
Ariel
Hi again,
Thanks!!
I already signed up.
Not sure you’re completely right. Assuming a Fcy of 4MHz (internal 8 MHz oscillator) for 24fj64 you can use a lot of baudrates within the 5% (microchip en026583.pdf). Even with a Fcy of 1 MHz you can use 19.2k whitout much trouble. Only a hint.
I’ll be glad to test (and give feedback of) any firmware you make (i’m a beta tester . Regarding to contact Matlab for a custom baudrate change… do you know how many RF-Explorers i could buy for the money?
Ok, i’ll take a look at it although i’m not familiarized with .net.
433MHz
Yes and no. We are experimenting in signal propagation through different snow and different frequencies. In our experimentation a couple of RF-Explorers are set in emitter mode (different frequencies) and buried deep into snow. The other is used as a spectrum analyzer logging data to a rugged PC. An arduino platform is not rugged enough for the test conditions we put the equipment into (maybe RF-Explorer also won’t but at least enclosure is more resistant)
Sweep is interesting to look for subtle changes in antenna behaviour when is in contact with the snow. That’s why i asked for.
If you prefer, we can continue this thread in the RF-Explorer groups.
BR,
Antonio
Unfortunately it is not that simple. You can get baudrates within 1-2% of the desired range up to 56K assuming an accurate 8Mhz clock, which FRC internal OSC is not. If you look into PIC24F datasheet, the FRC has a 5% tolerance already over the working temperature range. That means your baudrate generator has to be barely off by a max of 0.5% if you consider the FRC tolerance as well.
For real world experience on this problem, there is a nice thread somewhere about the problems Ian and team had on first PirateBus boards when trying to work at 9600bps+ with FRC.
In practical terms, there is no way you can get reliable communication with 8Mhz FRC on a wide temperature range except you get the baudrate very slow (i.e. 2400bps) or keep the baudrate tolerance itself close to zero (i.e. 100Kbps, 500Kbps).
It sounds like a neat project, I’m sure many readers will be interested in your setup. Let’s keep discussion in the RF-Explorer groups from here.