Radarcape only pushes to OpenSky when GPS locked?

Hi, as far as I can tell, I'm losing days of data at a time because my gps antenna is weak- Radarcape is definitely hearing transponders but Opensky only seems to get (approve?) the data if there's a GPS lock.

Is it possible to change this, or force it?

Thanks

How does your log file in Radarcape look for the opensky connect?

After a restart mine requires approx 30 seconds to get the accurate GPS time. But it starts immediately feedingt to Opensky

I've confirmed- openSky only recognizes the radarcape when the gps is active, which I infer means that radarcape isn't pushing when the gps isn't locked.

Log file- where on the disk can I find it?

It's in the Radarcape web interface, Status per feeder

Both statuses- openSky followed by GPS. Radarcape currently shows Red on the gps light, blinking 1hz which I understand to mean 'insufficient gps' signal.

I don't believe this was the standard behavior before I updated its code about a month ago. I could be wrong though.

Any ideas how to force it to continue feeding or where to ask?
Thanks

==

Opensky Network Feeder Status
Activity Log

04-04-2021 17:29:09(T) GPS time status change to GPS
04-04-2021 17:30:18(t) GPS time status change to GPS(unstable)
04-04-2021 17:30:19(C) GPS time status change to CPU(sync)
04-04-2021 17:30:21(t) GPS time status change to GPS(unstable)
04-04-2021 17:30:22(C) GPS time status change to CPU(sync)
04-04-2021 17:30:23(t) GPS time status change to GPS(unstable)
04-04-2021 17:30:27(C) GPS time status change to CPU(sync)
04-04-2021 17:30:49(t) GPS time status change to GPS(unstable)
04-04-2021 17:31:01(T) GPS time status change to GPS
04-04-2021 17:33:59(t) GPS time status change to GPS(unstable)
04-04-2021 17:34:00(C) GPS time status change to CPU(sync)
04-04-2021 17:34:01(t) GPS time status change to GPS(unstable)
04-04-2021 17:34:02(C) GPS time status change to CPU(sync)
04-04-2021 17:34:13(t) GPS time status change to GPS(unstable)
04-04-2021 17:34:23(C) GPS time status change to CPU(sync)
04-04-2021 17:37:08(t) GPS time status change to GPS(unstable)
04-04-2021 17:37:21(T) GPS time status change to GPS
04-04-2021 17:37:36(t) GPS time status change to GPS(unstable)
04-04-2021 17:37:37(C) GPS time status change to CPU(sync)
04-04-2021 17:37:58(t) GPS time status change to GPS(unstable)
04-04-2021 17:38:00(C) GPS time status change to CPU(sync)
04-04-2021 17:38:01(t) GPS time status change to GPS(unstable)
04-04-2021 17:38:12(C) GPS time status change to CPU(sync)
04-04-2021 17:38:16(t) GPS time status change to GPS(unstable)
04-04-2021 17:38:18(C) GPS time status change to CPU(sync)
---
GPS:
Operational Log

04-04-2021 17:34:01(C) Time status changed to CPU(sync)
04-04-2021 17:34:11(C) TrackingSatellites: True
04-04-2021 17:34:12(t) Time status changed to GPS(unstable)
04-04-2021 17:34:21(t) TrackingSatellites: False
04-04-2021 17:34:22(C) Time status changed to CPU(sync)
04-04-2021 17:37:06(C) TrackingSatellites: True
04-04-2021 17:37:07(t) Time status changed to GPS(unstable)
04-04-2021 17:37:21(t) GPS stable for 10 seconds
04-04-2021 17:37:21(T) Time status changed to GPS
04-04-2021 17:37:35(T) TrackingSatellites: False
04-04-2021 17:37:36(T) Status 35 BIN ALL CRC TSgps RTS FEC ACoff 3 0D AntOk notTrack GoodSat TimeUTC noSync FEC Daysec+1
04-04-2021 17:37:36(t) Time status changed to GPS(unstable)
04-04-2021 17:37:36(C) Time status changed to CPU(sync)
04-04-2021 17:37:56(C) TrackingSatellites: True
04-04-2021 17:37:57(t) Time status changed to GPS(unstable)
04-04-2021 17:37:58(t) TrackingSatellites: False
04-04-2021 17:37:59(t) TrackingSatellites: True
04-04-2021 17:37:59(C) Time status changed to CPU(sync)
04-04-2021 17:38:00(t) Time status changed to GPS(unstable)
04-04-2021 17:38:11(t) TrackingSatellites: False
04-04-2021 17:38:12(C) Time status changed to CPU(sync)
04-04-2021 17:38:14(C) TrackingSatellites: True
04-04-2021 17:38:15(t) Time status changed to GPS(unstable)
04-04-2021 17:38:16(t) TrackingSatellites: False
04-04-2021 17:38:17(C) Time status changed to CPU(sync)

Thanks, I'll try that too

That appears to have been how it used to work- I'm definitely seeing it stop feeding the minute it loses the lock and sit there- blink it's "I hear ADS-B" light and showing me that it hears airplanes going overheard, but the GPS light blinks 1 second red/amber indicating the gps is not locked.

That then correlates with "offline" amount of time as reported by the openSky dashboard.

This is new behavior as far as I can tell as of the update a few months ago- I'm trying to confirm on the radarcape side.

Additional note:
Jetvision has released a major update of their software on Radarcape and Airsquitter.
It now shows on the main page the status of the services including GPS status:

However i can confirm that the upload to Opensky only works after the GPS has been locked after the update/reboot.

fwiw, I updated it last night.

It appears to work the same way and I've got a red triangle noting:
No GNSS time synchronization
(/status.json)

In the meantime, I've ordered the cable I need to connect it to a better gps antenna.

I think the update was not intented to improve GPS Fix speed.
Did you report your issue to Jetvision? They are the developers and can give you more tips

strohmeier wrote:

I've asked our Radarcape people how it is intended is as follows: The Radarcape needs to have GPS sync once to start feeding, if it loses it after that, it shouldn't matter, however.

Hi- I've gone back and forth with radarcape support and you.

Everyone says that as soon as there's a gps lock, the feed will start and continue from that point, even if the lock is lost.

I've upgraded my antenna so that it's reliable and the attached image proves this isn't true.

At noon local time, I disconnected the gps cable to simulate a signal outage. You can see the red-outlined block of "offline" until 17:00 local, when I plugged it back in.

Within a minute or so of disconnecting it- openSky says I'm offline. Within a minute or so of reconnecting it, openSky says I'm back online.

Is it possible, that at some point, the code inadvertently changed to stop feeding without a gps time signal? Radarcape support is telling me that they're using your code which hasn't been changed in 5 years and that they don't have access to (is the code available somewhere?).

But I've repeated this experiment a few times now- it stops feeding quickly and restarts feeding as quickly.

>Did you report your issue to Jetvision? They are the developers and can give you more tips

Fwiw, jetVision says that the code is from openSky, hasn't changed in 5 years, and that they don't have the source- is that true or is the source available from somewhere?

I can prove that as soon as I disconnect the gps cable, it stops feeding, then when I reconnect it, it feeds again. Repeatedly, every time.

Hello all, developer here.

Yes, it is true that our part of the code did not change for years. If jetvision says its 5 years, it may be five, I thought it was even more. And for that time I did not touch the code, so I will have to look it up.

And yes: it is (still) closed. The reason for that is that it got so complex (not the code itself but the build system behind it: we supported a wide range of different front- and backends a long while ago) that I didn't want to release it in this state. On the other hand, it proofed to be so stable that I never had to touch it again, so my mindset is pending between "I should really clean up the messed parts and release" and "but it works so nice that I don't want to touch it". Plus I currently do not have the time to do it, unfortunately.

Back to the question, I just had a look at the source:

1. the radaracape tells me (I guess whenever it changes) about the 'GPS time status', which is one of 'invalid', 'cpu time' or 'gps time'
2. if that time status is 'invalid', the logic does not relay frames, and, conversely, if it is 'cpu time' or 'gps time', the logic relays frames

Especially: this does not take any previous state into account: if at some point in time we had 'gps time' and later we get 'invalid' again, it would stop feeding at exactly that moment.
So from my perspective the question should rather be: when exactly does the radarcape tell me which state. But that is again to be answered by Jetvision. And: that behavior might also have changed in some latest update.

It is actually possible to change the behavior of our filter and to relay frames even if the time is 'invalid'. But honestly, I don't know what would happen with frames which really have a messed up timestamp. And it doesn't sound like a good idea to me

Unfortunately, I also don't have a radarcape at hands. I just moved to another city and gave my development radarcape back.

Regards,
Markus

Thanks- that's just the info I was looking for.

I'm a dev too, so I understand what goes into tracking this kind of thing down. I'll talk to the radarcape support and probably get back in touch with what they say.