If you happened to get one of those $7 SDR radio dongles from ebay and need to put it to work... here's one thing I tried...
Tune in with the R820T... (Using HDSDR)
This is both radios running on one channel. They are out of tune enough that the channels don't even overlap!
Now I switch them into beacon mode and tune to 925.000 MHz...
Now I tune them up by adjusting the EZRADIOPRO_OSC_CAP_VALUE to get this...
Through the magic of special effects, I can overlay them...
Below are the before and after pics of normal transmissions (non-beacon mode)...
Here are the actual results I measured (warming up and final calibration)...
Ground = +7.3 khz @ OV 204 (cold)
Ground = +6.5 khz @ OV 204 (warm)
Ground = +6.1 khz @ OV 204 (hot)
Ground = +0.1 khz @ OV 208 (warm)
Air = -6.5 khz @ OV 204 (cold)
Air = -6.2 khz @ OV 204 (warm)
Air = -7.1 khz @ OV 204 (warmer)
Air = +0.6 khz @ OV 199 (warmerer)
All the pictures in this post are to the same scale. The FSK signals (wider pictures) are on a different frequency than the beacon signals.
Make any predictions on expected range improvement below...
Sorry for the delay in responding. I'm still kind of a noob with github. Some stuff initially got uploaded to the wrong branch. You can ignore the comments everything was compiled from the master SiK branch.
You don't need to worry about bootloader issues. Messing with the bootloader requires a SiLabs programming adapter, so you can't mess anything up with regards to that.
After loading one of the SiK-Serveurperso fimrwares (for a specified OSCVal), via the mission planner tool, I noticed the readme that says that some options were modified :
### "Max Window (ms)" replaced with "Bootloader Main Frequency Override"
Override the frequency band defined by the bootloader.
Warning, the use of a different frequency band than that provided by the matching stage of your board results in a dramatic performance loss!
- Valid values are 67 (0x43) for the 433MHz band, 71 (0x47) for the 470MHz band, 134 (0x86) for the 868MHz band, and 145 (0x91) for the 915MHz band.
### End of Serveurperso branch
Does this mean I should set the drop down list to "67" for my 433Mhz radios ? Jake, can you confirm ?
I get a clear spike at 434Mhz (I am not sure I see the 600Hz thing, whatever it is). But then what should be the procedure after the 30 sec signal stops ? I suppose I should compare it to another reference signal to evaluate what the offset is but there I'm lost with what I should do ?
I think it's 434MHz modulated with 600Hz, but as in my post from Friday it doesn't work like that in my case.
Pulsed signal is IMHO like normal operation FHSS - some precomputed pattern, between max an min frequency.
Thx Karol, that works.
Now I would like to understand the procedure :
-when I run ATJ, it emits a signal on the 434Mhz frequency for 30 sec (Jake says 600Hz, but what is that 600Hz ? is it 434, 600 Mhz ?)
-Then it emits a pulsed signal : on what frequency is itsupposed to emit that pulsed signal ?
I used realterm. Params: 57600 8N1. First input +++ without any line endings, and after OK reply use AT commands with Windows line ending (CR LF)
Finally took some time to test your 434 tune firmware. I loaded it via mission planner to the radio.
But then I can't get any reaction from AT commands. What is the baudrate you've set if any ?
(tried putty and arduino serial monitor)
I have a lot of trouble with my telemetry (range below 100m), so I checked my modems with Jake's firmware. I used commands: +++, ATJ, ATK, ATK, ATK. Every time it transmits on completly different frequency, where as far as I understand, it should do it on the same frequency (925MHz as printed in terminal).
Is it issue with Jake's beacon firmware, hardware bug (something with PLL lock?) or lack of my undrstanding beacon mode? I have the same results on two different modems. Below I attached a screenshot from SDR# when executing above commands.
Also amount of strong secondary transmissions from modem is horrifying.
Does anyone have any ideas of what might be the issue?
@ Jake i would like to collaborate with you because i am not able to write the code. first of all it would be interesting to find out if the AFC with the configuration we have right now is working or not. (in moment the setup for AFC is 0x44 instead of the default value from the data sheet 0x40) for this it would be helpful to have a AT command to read out the AFC tuning setting. can you implement that in the 433 or 925 software version?
With this reading we can see very easy if it is necessary to spend more effort to improve the Tx frequency accuracy.
@ JAke. Thank you very much for the time you put and the decision to share your findings. As per the nay-sayers its best to just IGNORE. Its much more attractive to listen to someone who put alot of experimental work into something rather than just theory talk and nothing practical.