Cheers Ross.
I looked back into my iGateās logs, and it seems it had a certain amount of trouble decoding the packets that balloon was sending. Not quite sure why.
I also noticed that the previous couple of days (Jan 15th and 16th) it has been very busy with APRS traffic, both directly and via G3CWI-13, G3CWI-13 and G1LPW-10. Seems to have quietened down today.
1 Like
Mine aswellā¦ here is the raw packet off the logsā¦
<165>1 - 2E0JWA-10 CA2RXU_LoRa_iGate_1.3 - - - RX / <SP2ROC-11>APZ34U,NOHUB:/121918h5109.89N/00234.80WO115/080/A=038011/P179S20T-25V260O17N1F3 Day28 / -127dBm / -14.25dB / 3597Hz
Ross @G6GVI kindly converted the GPS co-ords given for me, apparently its is a standard used for this sort of thingā¦ but LoRa-aprs.live doesnt seem to recognise it as a position, so I dunno!
looking at the timings i tracked it all accross this route
SO I was very pleased with that!
Alan
1 Like
I guess my iGate struggled similarly, though I notice I got 3 hits in the SondeHub page, so something got through.
I got 10 hits on Sondehub, so likewise! Something workedā¦ 
Alan
The observant amongst you may have clocked my second Igate 2E0JWA-11 Appearing this evening on the island of Walney! This will be the final location of the gate, in the mean time, it is on test at my home location in IO83XN. When I have deployed it, in its final location I will update everyone accordingly!
Thanks guys
Alan
4 Likes
OTA updating of LoRa Igates??
Has anyone used the OTA update feature?? I dont wanna balls anything up, so would appreciate an āidiots guide toā if anyone has one!
Thanks!
Alan
Yes I use it for updates.
Click the releases on the igate firmware page, circled in green in the picture below, to get the device specific list of zip files.
Download the zip file for your device, unzip and in one of the folders there is a file called firmware.bin.
Open the web configuration page on your igate, select the OTA tab and the when prompted for a file use the .bin file that you have downloaded.
Done 
The configuration should be intact but sometimes I get a message āconfiguration could not be loadedā but rebooting the igate seems to fix this without having to reconfigure.
3 Likes
ahhhh looks easy enough then, ill have go at that after then Thanks
EDIT Worked perfectly, Thanks!
Alan
2 Likes
Sometimes my iGate throws up anomalies in its logs. The position in this one is particularly weird: 
Jun 13 16:45:27 M0LEP-10 CA2RXU_LoRa_iGate_1.3 RX / GPS / G0FSD-15 / APLRT1,WIDE-1 / - / -118dBm / -4.00dB / 4885Hz / 152.47458N / 19.35364E / 10958.2km / LRT1,WIDE-1:=\4?GMMs@Xk7hQ
I assume itās a strangely-configured iGateā¦ 
This seems to happen either when an iGate without a GPS hasnāt had a position explicitly set but transmits a beacon packet, or when a tracker has not properly determined its position but transmits a fix packet anyway. The obvious symptom is that the latitude is outside the range -90 to +90. I have seen cases where the erroneous position gets corrected in a later packet, at which point slightly saner ranges get calculated.
1 Like
2E0KIO-10 is up in its temporary location. took a few attempts to set it up but its working. Iāll move it into the loft space and run some power to it in a few weeks.
3 Likes
Earlier in the year I built a mobile iGate (M0WIV-6) using a Heltec Wireless Tracker board. With a mobile iGate you donāt enter a fixed latitude and longitude but allow the on-board GPS to determine where it is.
The board worked well when I took it to France but after returning home I tried it again recently and it wouldnāt pick up any WiFi signal. So I simply reflashed it and thought I had configured it correctly but it is not updating its location, it still thinks it is in France. Iāve looked at all the settings but it still isnāt updating.
If anyone has made a mobile iGate or can offer any suggestions I would be very grateful.
EDIT: I have no idea why but it is now working! Please ignore the above.
1 Like
My guess is the GPS was having a spot of bother getting its first fix. Iāve had a Heltec tracker take an hour or more to get itself up and running. If the weatherās nice I leave them outside with a nice clear view of the sky, and they start more quicklyā¦
3 Likes
After noticing what seemed to be a ādead spotā for coverage in the Wigan Area I decided to install an igate at home. The dead spot was noticed from my commute that approximately 0.5miles from home as I drop down in Wigan , no igates picked up my tracker. On looking at aprs , very few packets seemed to have been received from the area sent by anyone, so why not give it a go.
So, I got the board and connected it to an old discone (which I know has a low(<1.5:1) swr on 2m,70cm and 23cm.
Sure enough, I now show being tracked right to my door and being reported to aprs.fi correctly by G7ADF-10 and G7ADF-7 is shown as being heard directly by G7ADF-10.
Now the issue. The Heltec board oled display has shown other data being received, but on looking on aprs.fi they do not seem to have been reported. For example on 31st July, the display on the board showed a last heard of G6GVI-11 (who I could see was in the Winter Hill area as reported by others). This doesnāt seem to have been reported to aprs.fi as its not shown as āstations heard directlyā.
So I know the igate works and reports correctly with my tracker (an unmodified sota tracker) but not showing anything else. Either Iāve got the setting incorrect, or Iām reading aprs.fi incorrectly or something.
Have I set up the board incorrectly?
Am I reading aprs.fi incorrectly?
Is it just lack of traffic over a short period of time and to wait (the coverage I expected is around 10 miles in a sector of around 90 degrees centred on South-West of Wigan (based on my normal UHF coverage) and I should wait?
Any pointers?
Ian
1 Like
Iāve a suspicion aprs.fi only remembers the ID of the first station to report a particular fix to it. This skews the stats somewhatā¦
1 Like
Iām no expert (and will gladly be corrected), but iGates will pick up all sorts of packets and all will be sent to APRS-IS, but if another iGate has already reported that same duplicate packet, one of them will be discarded by APRS-IS. It sounds like this is what has happened in the scenario you describe - another igate will have reported G6GVI-11 before yours. I think it works on a first come first served basis, i.e the iGate that reports a packet to APRS-IS first will be the one that is recorded as having heard that packet on sites like aprs.fi or aprs.to (which are just front ends to APRS-IS).
You often see this behaviour with digipeaters that are not connected to APRS-IS via an internet connection: you can be right beside the digipeater and broadcast a tracker packet only for a more distant internet connected igate to be recorded as having heard the packet. This is the first come first served thing coming into play: the distant internet connected igate was able to get the packet into APRS-IS quicker than the digipeater which will have heard the packet but needed to rebroadcast it via RF to be picked up by another igate (so inducing a delay).
As you are using the CA2RXU igate firmware, you can set it to upload all data it hears to this site: https://lora-aprs.live/ via syslog (see https://lora-aprs.live/help.html) - or set up your own syslog server on your network - itās quite interesting to see what your iGate is hearing but is not necessarily recorded by APRS-IS.
2 Likes
That all makes sense and explains what i am seeing.
I may try one of the options ton
see everything heard.
Many thanks.
2 Likes
Yes, thatās what happens. Whoever has the fastest (lowest latency) connection to the APRS Internet Stream has the advantage, and it also depends which of the Tier2 Servers youāre each uploading to.
2 Likes
