Minimalist WSPR tracker for pico-balloons utilizing Raspberry Pi Pico (or Rp2040) as the RF generator (aka The Cheapest Tracker In The World™). More info: [WIKI](https://github.com/EngineerGuy314/pico-WSPRer/wiki/pico%E2%80%90WSPRer-(aka-Cheapest-Tracker-in-the-World%E2%84%A2))
MIT License
50
stars
9
forks
source link
configurable 20,17,15,12,10 meter bands with u4b channels correct, cleanup on some other smaller things #50
the main thing was adding the 'A' command for bAnd which lets you set the band 10,12,15,17,20 (meters)
the u4b channel is used to figure out frequency, and the varying id13 and starting minute on each band
I did some stuff to keep the board from getting hungup with bad Klock_speed settings (too high)..for example checking that pico sdk thinks it's a good freq first (205 mhz isn't for example, can't do).
I cleaned up some null term char issues in the char arrays for config stuff. they should all have null terms now at all times, so you can print them with %s easily in messages
There were some issues in the two routines that check_data_validity and check_data_validity_and_set_defaults. I fixed some inconsistences and just use check_data_validity_and_set_defaults. It works better now for the case where the board got wedged due to bad clock settings in the nvram and you use a flash nuke program, but now all the nvram has bad config values. The bad clock issue shouldn't happen any more because of the prechecks.
I tested up to 220mhz. and a little testing on all 5 bands
I cleaned up the way the NMEA GNGGA is parsed in gpstime.c. It's more obvious now how variable length strings between the commas extract correctly (with the null terminator) and I added some checks for empty fields to make it more obvious how those cases are covered
I use 4 spaces intead of a tabstop on any code I touched. Tried to match the coding style otherwise
I put comments with "kevin" and the date around code I modified. Those can be removed post merge, but good for seeing what I touched.
At the higher frequencies (200mhz) and higher bands, there does seem to be an issue with losing the correct altitude because the GNGGA starts reporting bad altitudes even though it says the fix is good. This may be local to my test location with smaller number of sats. It seems clear it's related to the WSPR RF having a negative effect on the GPS if they're both on at the same time.
The GPS lat/lon/altitude should be saved at the beginning of the callsign wspr, and used for both that and the telemetry. I'm not sure if the code does that, or whether it can see GNGGA change during the duration of the two messages, and grab the change. Since you can cross a grid and get a new subsquare, you don't want to do that, and the lat/lon/altitude should be snapshotted before the callsign tx starts, and used for both callsign and telemetry tx
. I've not looked at what it does in that regard.
I removed all the files in the build dir (except for the .uf2) to eliminate clutter in my repo for the compare
I did some stuff on the voltage/temp wraparound, so the stdout messsages are not wrapped, and the wrapping happens with module arith in the wspr packet creation.
the voltage to stdout is adjusted to be a multiple of 0.05 volt so it should be a better indication of what gets sent out as telemetry. Left temp with one digit of precision (which telemetry doesn't have) because it might be interesting to see small shifts in temp while testing
knormoyle
commented
1 month ago
the main thing was adding the 'A' command for bAnd which lets you set the band 10,12,15,17,20 (meters) the u4b channel is used to figure out frequency, and the varying id13 and starting minute on each band
I did some stuff to keep the board from getting hungup with bad Klock_speed settings (too high)..for example checking that pico sdk thinks it's a good freq first (205 mhz isn't for example, can't do).
I cleaned up some null term char issues in the char arrays for config stuff. they should all have null terms now at all times, so you can print them with %s easily in messages
There were some issues in the two routines that check_data_validity and check_data_validity_and_set_defaults. I fixed some inconsistences and just use check_data_validity_and_set_defaults. It works better now for the case where the board got wedged due to bad clock settings in the nvram and you use a flash nuke program, but now all the nvram has bad config values. The bad clock issue shouldn't happen any more because of the prechecks. I tested up to 220mhz. and a little testing on all 5 bands
I cleaned up the way the NMEA GNGGA is parsed in gpstime.c. It's more obvious now how variable length strings between the commas extract correctly (with the null terminator) and I added some checks for empty fields to make it more obvious how those cases are covered
I use 4 spaces intead of a tabstop on any code I touched. Tried to match the coding style otherwise I put comments with "kevin" and the date around code I modified. Those can be removed post merge, but good for seeing what I touched.
At the higher frequencies (200mhz) and higher bands, there does seem to be an issue with losing the correct altitude because the GNGGA starts reporting bad altitudes even though it says the fix is good. This may be local to my test location with smaller number of sats. It seems clear it's related to the WSPR RF having a negative effect on the GPS if they're both on at the same time.
The GPS lat/lon/altitude should be saved at the beginning of the callsign wspr, and used for both that and the telemetry. I'm not sure if the code does that, or whether it can see GNGGA change during the duration of the two messages, and grab the change. Since you can cross a grid and get a new subsquare, you don't want to do that, and the lat/lon/altitude should be snapshotted before the callsign tx starts, and used for both callsign and telemetry tx . I've not looked at what it does in that regard.
I removed all the files in the build dir (except for the .uf2) to eliminate clutter in my repo for the compare
I did some stuff on the voltage/temp wraparound, so the stdout messsages are not wrapped, and the wrapping happens with module arith in the wspr packet creation. the voltage to stdout is adjusted to be a multiple of 0.05 volt so it should be a better indication of what gets sent out as telemetry. Left temp with one digit of precision (which telemetry doesn't have) because it might be interesting to see small shifts in temp while testing