mirror of
https://github.com/richonguzman/LoRa_APRS_iGate.git
synced 2026-10-31 02:51:58 +01:00
Portable iGate: How to use the internal GPS of T-Beam #137
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/LoRa_APRS_iGate#137
Reference in new issue
Block a user
Hello Ricardo!
As far as I know it is only possible to configure fixed, static coordinates into your iGate software. Is there any chance to use the GPS (e.g. of the T-Beam) and use these coordinates for the iGate.
I am thinking of building a portable iGate that can be used from different locations ...
73 Martin
OE5REO
I just talked to the Gods of APRS and asked about this feature: we have green light... so I will start doing this in next days ;)
That's great news ... thank you.
If possible you should consider adding the feature "position ambiguity" also:
https://blog.aprs.fi/2011/01/position-ambiguity-support.html
ok, but why? the iGates already have been doing this without ambiguity. Or I should add ambiguity for trackers too?
When running a portable iGate you probably wouldn't want to tell "the whole world" where exactly the iGate is located. With fixed coordinates you can choose to alter the last digits a bit so not everyone sees the exact spot of your loaction. I did that with my APRS- and LoRa-iGates at home, they are shown on the map about 30-50m away of the real position:
I would like to use the LoRa iGate in my car when I'm out hiking ... POSITION AMBIGUITY would be a simple and easy way to obscure the exact location of my car/iGate a bit.
so for igate is ok ambiguity but for tracker not. (I'm not trying to make fun of this , but just to be clear about what the request is)
For me personally it is only important for iGates (when using the internal GPS). Not for trackers ...
But there are probably other users who would like to see that option on the trackers as well!?
i was thinking about this too.... will check how to add this ambiguity as it a clever request ;)
do you want to test?
as github branch (not webflasher)
Hi Ricardo,
just tested and it works ... but there is a slight difference between your approach and the one that can be configured in DireWolf and APRS devices like Kenwood or Yaesu.
It seems that you take the last two digits of the latitude and longitude and round them whereas in DireWolf and with other APRS radios the operator can choose how many digits should not be displayed (e.g.: Kenwood, Yaesu):
I have configured a 1-digit ambiguity in my portable APRS iGate running DireWolf ... a pink rectangle on the map view appears if i hoover the mouse over it ... with every new beacon the symbol moves a bit within that rectangle:
Please take a closer look at the raw data ... there are "blanks" instead of the last digit of the coordinates!
!4754.3_NR01407.7_E
These are screenshots of the LoRa iGate using internal gps:
So your configuration works perfect ... just wanted to let you know that there is a different approach to the subject in other APRS software and devices like DireWolf, Kenwood, Yaesu, ...
For me personally the option with choosing how many digits of the coordinates should not be transmitted (like in DireWolf, ...) is better. Not sure how difficult it is to implement into your software!? Thanks for your quick response ...
73 Martin
OE5REO
Martin,
as you already (may) know, there are a few ways to send GPS data: no encoded, Mic-E encoded, base91 encoded.
LoRa Tracker/iGate (my version) runs with base91 encoding for shorter packets. The only problem for this is that ambiguity, like you describe (with the box) runs on "no encoded" and Mic-E only.
The position of the stations is set randomly in this "red box" for this ambiguity. The only way I could find to keep on being base91 encoding is to avoid using more than 2 decimals for GPS (this gives ~1.1km ambiguity). Using only 1 decimals gives 11kms ambiguity. No decimals 111kms.
so "for this test" we have a fixed 1.1Km ambiguity but I can add a selectable "error" for next versions.
Thank you very much for the information .... I heard about Mic-E and base91 but did not know exactly what was the difference. Also did not know that Position Ambiguity is only available for Uncompressed and Mic-E beacons.
So thanks again for adding this feature ... I think an ambiguity of 1.1km is enough, no need to make it selectable for 11km or even 111km. Would be nice to have an ambiguity of 111m, but that's not possible with base91 if i understand your comments correct.
it can be done for sure
maybe we could add a variable ambiguity selector for 111mt, 1.1km, 11km
for initial test I guess 1.1km is enough, right?
That would be great! 1.1km is enough for testing, will do so in the next days ...
Did a short test ... worked fine but I think that AMBIGUITY with the current settings is more than 1.1km! I made a screenshot:
The other dots on the map are my APRS beacons from the car (OE5REO-9). The difference between the location of my iGate/car and the coordinates of the transmitted beacon was more than 5km. Experienced this two times.
Later I noticed that on the webinterface I can send beacons manually ... so for the next test tomorrow I will not have to wait 15 minutes :-)
manually should not be done (as this is not ment to be a tracker)
are this 2 beacons gps points how far away?
i know ... i did this just for testing purposes and only via APRS-IS (no TX on 433MHz).
i am not quite sure what you mean ... here is the explaination of my screenshot:
when the igate sent out the beacon (via APRS-IS only) i was at this position:
but the beacon showed up on the map here:
there is a distance of over 5km between these two points (line of sight) ...
same with second beacon ... i was at this position when the igate sent out the beacon (via APRS-IS only):
but the beacon showed up on the map here:
there is a distance of over 4km between these two points (line of sight) ...
that is why I thought that AMBIGUITY is more than 1.1km
I get it, but can you check the real positions for both of this points?
they should be XX,XX00000 both for latitude and longitude
will test the igate on friday on my sota activation. i will leave it in the car for a few hours and will take my tracker with me on the hike. afterwards i will report here how it worked ...
The test of the iGate today was very positive ... the packets of my tracker were received quite well with a small magnet mount antenna on the roof of the car. I placed the iGate in the trunk of my car where GPS reception seems to be very poor, the T-Beam did not get a GPS fix for several hours:
Will do further testing ...
73 Martin
OE5REO
i see to improvements to this:
what do you think?
it probably makes sense ... although i found it very useful for testing purposes during my hike to see that the igate was still operating
but when the device is turned off and then on again it should not send the last validated GPS position (because igate could have been moved to another location ...)
by last validate GPS data I mean the last from boot up (not any saved from another day or before reset/boot up
GPS added to Release V2.1 ;)