FIrmware 0.52. Three ArduSimple RTK3B boards with WIFI NITRIP Master XBee boards fitted.
Board 1 (RTK Base) is transmitting RTK data to both Rovers (Boards 2 & 3).
No NTRIP functionality enabled.
Using Socket Server/Client for RTK transport- Socket 23 over TCP - Base TX rate is approx 3.5kB/s
Each Rover is transmitting NMEA data via their Socket Server (TCP/23) to a logging PC - TX rate for each is 1.7kB/s
A (physically) local Access point is provided for all three units to connect to. The logging PC is also a client of this access point.
As physical distance between any of these units and the access point is increased, a triumvirate of panic resets occurs. The only way I can operate this setup is with the units placed within a square metre of each other. RSSI at this distance is -(20-30)dBm. At a single unit removed to a distance (12m or so) where the RSSI is reduced to -55dBm, the system is unworkable due to the frequency of panic resets.
Reflecting upon the fact that at extended distances, the use of TCP could be extending message queues to the point of creating a panic reset, I decided to switch to UDP. Since the odd lost packet makes no real difference to system performance, UDP seemed a reasonable thing to try.
Simply selecting UDP as the transport (instead of TCP) albeit leaving the port at 23, caused a stream of constant panic resets. I was able to capture a core dump (attached) before aborting the experiment and reverting to TCP.
Attached is a core dump from a Rover unit after attempting UDP Socket 23 transport.
Attached is a log file from a Base unit when setting UDP Socket 23 transport.
esp32_xbee_v0.5.2_core_dump_dd4176.zip
RTK Base UDP errors.pdf
FIrmware 0.52. Three ArduSimple RTK3B boards with WIFI NITRIP Master XBee boards fitted.
Board 1 (RTK Base) is transmitting RTK data to both Rovers (Boards 2 & 3).
No NTRIP functionality enabled.
Using Socket Server/Client for RTK transport- Socket 23 over TCP - Base TX rate is approx 3.5kB/s
Each Rover is transmitting NMEA data via their Socket Server (TCP/23) to a logging PC - TX rate for each is 1.7kB/s
A (physically) local Access point is provided for all three units to connect to. The logging PC is also a client of this access point.
As physical distance between any of these units and the access point is increased, a triumvirate of panic resets occurs. The only way I can operate this setup is with the units placed within a square metre of each other. RSSI at this distance is -(20-30)dBm. At a single unit removed to a distance (12m or so) where the RSSI is reduced to -55dBm, the system is unworkable due to the frequency of panic resets.
Reflecting upon the fact that at extended distances, the use of TCP could be extending message queues to the point of creating a panic reset, I decided to switch to UDP. Since the odd lost packet makes no real difference to system performance, UDP seemed a reasonable thing to try.
Simply selecting UDP as the transport (instead of TCP) albeit leaving the port at 23, caused a stream of constant panic resets. I was able to capture a core dump (attached) before aborting the experiment and reverting to TCP.
Attached is a core dump from a Rover unit after attempting UDP Socket 23 transport.
Attached is a log file from a Base unit when setting UDP Socket 23 transport.
esp32_xbee_v0.5.2_core_dump_dd4176.zip
RTK Base UDP errors.pdf