I actually disagree with this. From tests that I did the slowest data rate performs very bad on a mobile node. The best reason I can think of is that you get fading of the link as you move, and therefore long sequences of bit erasures with which the forward error correction can not deal. I’d rather send 10 packets at the fastest data rate, than one at the slowest. The short moment that you have a good link at least you’ll get one full packet through.
My test setup is an Arduino + RN2483 at data rate 5 (sf7), power 14dBm. Source code on my github page, results on JP Meijers
The Fastloc GPS gives 3bytes (sat# + RSSI) per satellite, with a maximum of 12 satellites per acquirement. We currently use 8 sats (24bytes) per measurement as we found it enough to give a precise position.
The Fastloc is not used for continuous measurements, it is to be used on a trigger thus consuming very low power. (30ms+12s)
Its only meant for applications where power is the most important variable in the equation not cost nor speed.
The cost is prohibitive for hobby work. We are talking of £1k per unit.
Does the sensor node also have a very accurate real time clock? If you only have the RSSI values of the satellites, but don’t know when the measurement was done, you also won’t know where the GPS satellites were at the moment in time. Or is there another trick that is used?
Yes it has a very accurate RTC clock, around ~1…2ppm, constant temperature calibration.
A timestamp is always sent/logged with Sat data.
At server side, when data is received, it will be computed to reach a Lat/Lon “real” value. It can then be plotted/graphed/…
Knowing which Sat it is and its RSSI, we can use these values with Keplerian data and perform all calculations. All done at server side to save power and time at Node side.
I just ordered a navspark and navspark mini, seems like they could be useful combined with a HopeRF module to build a portable range tester (just let it send out its own position through LoRaWAN regularly and carry it arround, then later analyze the transmitted data to see how far each gateway can see).
Looking at the number of pins on the NavSpark mini, this should be just enough for this. It has 7 I/O pins: MISO, MOSI, SCK, SS, DIO0, DIO1 and DIO2. RESET is not strictly required I have found, and if only LoRa (not FSK) is used, DIO2 could be left disconnected too. This does not really leave any pins for attaching actual sensors, though…
Looks great, I would be interested in one, however the board that @matthijs and I are having a look at is a little different, see here. It has the GPS logic on board and allows to use the microprocessor (100MHz 32bit LEON3 Sparc-V8 + IEEE-754 Compliant FPU, 1024KB Flash Memory + 212KB RAM) for Arduino sketches.
I am in the process of testing this very small step-up/ step-down voltage regulator S7V8F3 Pololu 2122
connected to a lipo… if the voltage drop to, let’s say 2.9 v… you still have 3V3 available.
And if your charging your node @ 4.2 V it can continue working @ 3V3.
Found it in one of my favo online shops (NL) and will write about it some more next week.
