Needs specialist hardware in the Gateways.
There was a time when @borroz posted the logs of a packet arriving at 3 gateways. According to the time stamps the gateways were some 1000km+ or more apart, although in reality they were in the same room.
This tell me a latency issue between gateway and network server affecting the timestamp.
If I recall flight path bent in the wind taking it in Marseille direction once it had crossed the English Cannel towards Brittany/Normandy otherwise original track would have been close to the original Semtech/Cycleo dev team team down in Grenoble area 
Sure I recall some SMTC sales and apps guys + mktg team using on LoRa presentations for a while there after - until next record… 
Erm, nope, it’s RSSI all the way with the system that uses RSSI as the Semtech API requires the RSSI - you may see a pattern forming here …
If you want to “Go Large” then there are the gateways with the extra FPGA that can back calculate the time of transmission / time of flight - but that’s a totally other thing as it relies on suitably equipped gateways with owners with suitably equipped (or deep) wallets. And for this application, they’d have to be spread across the UK, France and the top half of Africa.
The packet forwarder does supply a timestamp to the backend. However for triangulation use specific hardware is required which provides higher resolution time stamps in a proprietary format which only Semtech can decode.
Asset tracking of animals (esp. birds) isn’t easy. I continue to refine my designs for this purpose to reduce weight and/or improve the form factor. This is my latest device:
It is designed to make use of an AA-size battery. This version has a boost converter for using alkaline batteries but I found this too noisy so removed it on the next. It is 7.1 g without battery (maybe a bit less w/o the AA battery holders): For cow or horse tracking, etc this is much cheaper, smaller, and lighter than most other solutions; a 3.6 V LiSOCl2 battery can last many months or even a year depending on duty cycle. The advantage here is there is no need for an external GNSS patch antenna since the CAM M8Q even with just a 16 mm x 62 mm pcb ground plane is surprisingly efficient.
For birds I would not use an AA-sized battery, of course, but a small LiPo. But then one might expect the device to last for only a few days. In my testing of the Gnat (which is very similar in power consumption) a typical fix uses ~0.5 mAH, so a 100 mAH LiPo battery would allow ~200 fixes. The battery life then depends on the duty cycle and battery size.
It turns out that there is some interest in cat tracking and of course, sea turtle tracking where this kind of solution is used in size and with success.
For smallish birds, I think such GNSS tracking might be too burdensome but the solution above could work well for raptors such as falcons and Eagles, for example.
In either case, the CMWX1ZZABZ-078 module is very hard to come by. I am working on a successor that uses the Murata Type 1 SJ module which can be sourced.
It is unlikely that any LoRaWAN-enabled GNSS tracker could be made that is smaller and lighter than these devices without costing many times the $80 Gnat price.
1 Like
Going to disagree with that - your board design is driven by the AA battery connector size, and made in a thick process, I’d guess just the bare PCB weighs over 2 grams.
Plus there’s still a USB connector and the real estate to support that, the antenna is connectorized…
Something that was serious about weight without revisiting the design of the GPS itself would put something like an STM32WL or similar on the opposite side of a thin multilayer board from the GPS receiver.
Yes, this particular design could be made smaller like the Gnat, perhaps. But then would need an external patch antenna.
Smart watches and even smart rings have GNSS and are much smaller, but then again, much more expensive.
The goal in my designs, at least, is as small as possible while keeping the useful features. So yes, one could drop USB and make some other compromises, and in custom solutions we do. This kind of design is intended for the average Arduino user, so trades some weight/size for utility.
However, if you are aware of similarly-small LoRaWAN-enabled GNSS asset trackers available for ~$80 I would very muck like to know about it.
I’d suggest doing what I’ve done for micro RC stuff, which is getting a centigram scale and start weighing components, including a model of what PCB area costs as mass and what you can save by going to a thinner substrate.
On thing I noted from the parrot tracker was that the antenna is shared between the RF transmitter and the GPS, presumably with a suitable small RF switch.
GPSs do work well with simple wire antennas, usually quite a bit better than the small ceramic chip things.
LOL, nice diagram.
I never said it was a good system but for outdoor devices that move occasionally it does offer some sense of location - the conclusion I came to after trying it out briefly was that I’d have to wait for a use case to come along that fitted the scenario nicely.
And now I/we have!
Plus for large agricultural areas there is the potential for using it to track livestock whilst keeping the cost & device size down. As I’ve used RDF in the past to recover a balloon payload, some fine tuning may be feasible with some sort of portable receiver.
Well as you mention it.
Radio Direction Finding (RDF) is a common technique for bird trackers etc, all the transmitter needs to do is put out a beep beep, this makes transmitters simple. Then you point a directional antenna for the loudest beep which is quite easy to do.
So lets say you have a TTN bird tracker, and you notice it has not moved for a couple of days. Finding it by picking up the LoRa signals and looking at the RSSI on your portable receiver is possible, but not so easy in my experience.
But there is, in my opinion, a better way of finding your lost TTN node, but still using RDF.
You make the LoRa device transmit an FSK signal. With an FM audio receiver (squelch off) you wave your directional antenna around and as if by magic all the audio noise the FM receiver is putting out goes quiet when it picks up the FSK. The noise comes in and out quite well and its easy to get a good fix on the direction of the node.
Now at 434Mhz this type of RDF is easy and I have used it to get accurate direction fixes on a particular orbiting satellite. An el-cheapo FM handheld will do for the receiver and there are plenty of directional 434Mhz antennas about.
With 868Mhz then finding a FM receiver is not so easy but a cheap SDR running on a laptop is a reasonable substitute.
Its also possible that the 868Mhz LoRa device could be used for 434Mhz FSK, although the RF output is around 8dBm down (dont try this at home folks).
So FSK RDF might be worth a try, although the node would need some form of motion detector so it could switch across to ‘find me mode’.
Hi,
I have made a bird-tracker together with a friend for a company and did a lot of measurements with SwisscomLPN. Including investigation of delta-distance between GPS-LoRaWAN_location_solving. Send me a PM.
BR
Lukas
1 Like
You can’t share it here so we can all benefit from your learning’s?
Hi,
I will come back I need to discuss how or if it could be posslble.
BR
If what could be possible ?
Hi,
We are still in discussion on what/if we can share.
What could you expect: informations about/how to build:
- Tracker 1g
- LiveMap implementation with track
- Empirical data about LoRaWAN precision in different topographic areas
- how to configure the filters to get a better precision
- Battery calculation tool
- Flashing tool
- Commissioning tool
- how to implement human readable commission data (for backups)
BR Lukas
1 Like
Well for me - I had a closer look at the closest (~12) gateways that was near me. There were quite a few issues, so I don’t think this would work very well.
- Most of them are in urban areas and indoor - the length of transmission that they can receive is mostly less than 500m in urban areas, as they are also mostly located indoors themselves. There were a few ones (I assume they’re located on rooftops or so) that could reach and even cross the 5km, but 2/12 is not too good of a score. That would mean that already not so frequent network could work for only ~20%? I know it’s a huge estimation, but well, I’m working with the data I have.
- With one - I received no data at all. Don’t know if the coordinates are wrong or what, but if somebody else tries this out - there could be this issue too.
- Some had issues with coordinates. They were incorrect. I wrote to the owners of the gateways, but no answer still. If they’d actually be at the coordinates that was shown, I don’t think I’d receive the data.
- I understand, that it was already written that timestamps wouldn’t do, but well I received some ridiculous data - data with two day delay.
- As for RSSI values, well it wouldn’t be high precision as mentioned before, the RSSI values (without changing location) showed up rather different, I did some possibly doubtful calculations with potential formulas and values, the result would be mostly that the error is around 500m, but in some cases even 2,5km. Not a precise science, but this seems that the biggest issue is that most of the receivers wouldn’t even receive the data whatsoever.
It’s possible that the issue is just with the nearest receivers I have, but well, I’m just sharing what I got, as it looks like there is some interest in the issue. And I have to add that I was testing it out mostly on ground level. I had one tryout on higher ground (80m above), but it didn’t magically prolong the receiving distance for one receiver that was less than 2km way - it still didn’t receive anything.
Useful review of reality - but it only applies to the place where you are. If you can give us your approximate location there may be some observations forthcoming from the community.
Gateways being offline or intermittent is bad but as a community network there’s not much that can be done to enforce this. And the same with location of the gateway.
I can’t account for data with a two day delay - I can think of a number of scenarios where this could happen but we’d need to see the meta data to figure that one out.
Overall I would suggest you extend the range of your evaluation - given that your bird could be anywhere and also that if the device is transmitting in flight that it will be heard by many different gateways, you may get some more useful results. The former you can test by a long drive, the latter with a drone.