RTK+PPP

[gauteh]

• Configure and log RTK+PPP (@edwinrainville) (Set up configuration settings for PPP-RTK receiver and sets up json output from send data to sfy #175)
• Get access to ublox PointPerfect (@edwinrainville any news on this?)
• Read and transmit ublox telegrams using sfy (@gauteh) (requires Upgrade all drivers and firmware to use embedded-hal #172)
• Add stronger power regulator (Pololu? or Scoop) - already at max (Notecarrier B v3.1: causes interference with IMU I2C at 1MHz #169).
• Use web.post for real-time: Real-time transmission of data #174

• https://www.sparkfun.com/products/22560

[jerabaul29]

Regarding power regulators: I have been very happy with https://www.pololu.com/product/2122 on the OMB (comparative list: https://www.pololu.com/search/compare/133 ). Curious: what is your design as of now? Are you "just" using the built in LDO regulator of the Artemis board and / or a LDO on your PCB? :)

[gauteh]

Currently we use the regulator on the notecarrier. Reluctant to use the artemis one since it appears to be less efficient (and it cannot take low voltage).

[jerabaul29]

Agree that using the Artemis LDO is probably not a good way :) .

[edwinrainville]

I have the PointPerfect account set up from ublox and got us a 2 month free trial of the L-Band broadcasted PPP correction data.

Here is also a link that the support staff sent me on the correct configuration of the combo ZED F9P and NEO D9S board. https://developer.thingstream.io/guides/location-services/pointperfect-getting-started/pointperfect-l-band-configuration

I was also following along with an example setup I found for the combo board and was looking into how to modify this to allow us to log the correction data. This example code configures the combo board through a qwiik connection with another board such as the Artemis nano I have been playing with. It is a little unclear to me if the configuration firmware is saved on the combo board or the main logger using this version. While I think having a firmware code that we can version control and reproduce for other buoys - a lot of the examples suggest using the U-blox platform to set it up.

[gauteh]

Sounds great! I think for playing around with the configurations and figuring out what is good, the ublox platform is nice, but at some point we need to send the equivalent parameters over the firmware. We could probably even skip that for now (if we don't have time) as long as the configuration is saved persistently to flash or similar.

That means we run of of the subscription before the experiments, have to remember renewing that before we go.

[edwinrainville]

Sounds good! I will make a note right now to renew the subscription before going in November. I have not activated the subscription yet either so I will activate it as soon as the new board arrives.

[gauteh]

Great, thanks!

[gauteh]

• Connecting A0(RX1) to ext-gps-mod TX
• Connecting A16(TX1) to ext-gps-mod RX
• Connecting A2 to PPS

[gauteh]

@edwinrainville we need to figure out if the F9P produces PPS every sample (20 Hz) or every 1Hz, otherwise I need to read a different number of telegrams on each pulse. I am guessing/hoping every 20 Hz. That is probably also the reason they named in time pulse (TS) over PPS.

[edwinrainville]

I'll see what I can find in the documentation on how the TP setting is configured.

[gauteh]

You can just try to set it here (or the equivalent place in your code): https://github.com/gauteh/sfy/blob/main/sfy-buoy/sfy-ext-gps/ext-gps-mod/gps.cpp#L31 (to 20 Hz) and see what happens.

[gauteh]

sfy1 ext-gps.pdf

[gauteh]

I'm trying to calculate ranges for serializing the lon and lats into u16s (https://github.com/gauteh/sfy/blob/main/sfy-buoy/src/gps/wire.rs#L19):

// The distance movable within one packet length of maximum 20 seconds. For 100 km/h this is
// (100 * 1000 / (60 * 60) * 20 ~= 550 m
const MAX_KM_PER_DEGREE: f32 = 111.3;
const DEG_PER_M: f32 = 1.0 / (111.3 * 1e3);
pub const LON_RANGE: f32 = 2.0 * DEG_PER_M * 550.0 * 1e8;
// pub const LON_RANGE: f32 = 2.0 * 1.0e8 * 550.0 / (MAX_KM_PER_DEGREE * 1.0e3); // 550 m in both directions
                                                                        // [deg * 1e-7]
// Maximum distance within 20 seconds: 60 m ?
pub const MSL_RANGE: f32 = 2.0 * 60.0 * 1.0e3; // 60 m in both directions [mm]

It seems that 1e8 of a degree is 1.113 mm? Assuming a worst case scenario of 111.3 km per degree. Is my thinking right? With a maximum of 550 m movement in 20 seconds (100 km/h over 20 seconds) this gives a worst-case resolution of 16.8 mm.

550 / (2^16) * 1e3 = 8.392333984375

@edwinrainville: are the lon and lat values sent in their highest resolution variation? Should they be u32s and not f64s? It looks like the JSON serialization uses engineering notation.

[gauteh]

@edwinrainville: I think the output frequency for the solution is now set to 1 Hz, does that one need to be increased if the TP frequency is increased?

[gauteh]

• added a on/off switch so that capacitors won't mess up voltage levels
• swapped to new batteries
• handle more panics in GPIO / RTC interrupt

test running from 10:21 local time @ 5 hz.

[gauteh]

Have had a test running from 11:43 LT without errors now @ 5 hz. will be useful for testing downloading and parsing data.

[edwinrainville]

Awesome! I'll download some of the recent packets and work on some of the parsing! Any updates on the RTK fix? Do you see a correct decryption?

[gauteh]

Any updates on the RTK fix? Do you see a correct decryption?

I haven't really tried, just using the poorer antenna in the office. I have focused on getting the firmware stable.

[edwinrainville]

Sounds good! Just was curious!

[gauteh]

I'm also working a bit on downloading collections of egps packages. I will move on to the real-time transmission in a bit (#174 ). Helge is back, he was wondering if we want him to work on the blue robotics or if you have a plan for it? He is doing a variation with PVC pipes probably.

[edwinrainville]

I have a general idea of what to do with the blue robotics bottle. I will be back tonight and I think I'll just pop in and take a look at the housing and maybe we can meet up with Helge tomorrow morning and see wha the thinks?

[gauteh]

Good plan! I soldered on a switch on the board (1 is off, 0 is on...), we need to solder up the next RTK buoy as well so that Helge can start working on it.

[edwinrainville]

Sounds good! I'll get the second one soldered up tomorrow morning and update the firmware on it!

[gauteh]

Ok!

[gauteh]

This is 40 minutes of elevation from the GPS, varying. Changes about 20 cm in 40 seconds worst case (this is with a pretty poor fix, no RTK, etc).

[gauteh]

Added the stationary test-data here if you want to take a look: https://github.com/gauteh/nazare/issues/5