@ BoRRoZ…very nice…the breadboard stand
Any idea how much raw data? Data packet sizes that can be sent with LoRaWAN are very limited; see the FAQ.
@arjanvanb The quantity of data you can take from it its entirely up to you. It outputs the pseudo-data from satellites if “views” and not the NMEA coordenates. Its a diferent concept.
Developers are used to traditional LAT/LON coordinates in NMEA packets at 1sec intervals while the GPS engine wastes away precious juice by being continuously operating. Even putting the GPS to sleep and wasting ~10uA is too much.
Fastloc concept is to get a map of the sky. And that map says how many sats there are and their RSSI values. All this done in mili-seconds. These pseudo/raw values are then sent downstream and calculated to get precise LAT/LON in the server that has immense computing power to use. While freeing the remote nodes to conserve power instead.
This concept originated in the animal tracking community a while ago with the intent of extending trackers life time.
and @arjanvanb wants to know how much data that “map of the sky” is… probably MUCH more byte hungry than simple lat/lng data. and LoraWAN is not suitable for big packets of data
…and moving nodes [might; see responses] always need to use the slowest data rate, and then are bound to a maximum application payload of 51 bytes (?), which will take almost 2.5 seconds to transmit. And if true, then with TTN’s fair access policy of 30 seconds a day such 51 bytes would only allow for an average of sending one location every two hours…
So, you might really want to keep packets as small as possible, @sergiosena. Let’s discuss that in a new topic: Best practices when sending GPS location data (which also has the references to my claims/assumptions).
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 http://jpmeijers.com/ttnmapper/kml
Spreadsheet for LoRa airtime calculation
Best practices when sending GPS location data
Why is ADR only relevant for nodes at fixed positions?
Location by triangulation
Use own STM32L151 + RFM98W module. Can insert to RPi or standalone
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…
Plan on doing the same, don’t forget to order an active GPS antenna
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.
give me a PM with your shipping address
they finally arrived and are charging @ the moment – (will be continued and tested)
Nice cases! The carton as well
Did you take Energy Harvesting May Break LoRa, SigFox LPWANs (that you posted yourself) into account when choosing those solar panels?
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.
Yes the same package for me
read the manual before putting it in the sun for a whole day
you need to switch it on first with a small metal pin.