|
Lerk
|
|
|
Group: Forum Members
Posts: 19,
Visits: 0
|
Have I got a setting in the wrong place somewhere then?
If I try to start a flight using pilotaware and the pilotaware isn’t ready it gives me the “no position has been received for some time” error and then shuts down the flight.
(Edit: just tried to start a flight without my paw in range and noticed it may be no connection to device warning that popped up - will do a quick experiment later today)
I’d have to check but I don’t believe it even creates a log for that session.
|
|
|
|
|
Lerk
|
|
|
Group: Forum Members
Posts: 19,
Visits: 0
|
Just done a trial by removing the gps source from my pilotaware.
The failure is that the wifi hasn’t booted up until ~2m10s where the comms handshake timeout looks like it is set at 15s for any occasion.
After starting a flight post boot (but with no gps) I started engines and waited 3m before pulling the power to pilotaware. 15s later the comms loss error popped up and the flight was scrapped with no log
I did this again but also selecting off blocks with the same result.
Is there a user selectable comms loss timeout hidden in the menu or is it hard coded?
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 7.8K,
Visits: 8.4K
|
It's hard coded, but that shouldn't be a problem. It sounds like your traffic receiver is ceasing to transmit anything to SkyDemon just because it hasn't got a GPS fix. That's a problem. We do expect your traffic receiver or GPS device to continuously transmit data to SkyDemon even if it doesn't have a fix. That's standard behaviour and it's how we know your device hasn't died. It can just transmit "no fix" sentences to SkyDemon, which isn't a problem.
Perhaps you could ask its manufacturer to clarify why they don't accept a connection until they have received a fix, and why they stop transmitting data if a fix is lost?
|
|
|
|
|
Lerk
|
|
|
Group: Forum Members
Posts: 19,
Visits: 0
|
+xIt's hard coded, but that shouldn't be a problem. It sounds like your traffic receiver is ceasing to transmit anything to SkyDemon just because it hasn't got a GPS fix. That's a problem. We do expect your traffic receiver or GPS device to continuously transmit data to SkyDemon even if it doesn't have a fix. That's standard behaviour and it's how we know your device hasn't died. It can just transmit "no fix" sentences to SkyDemon, which isn't a problem.
Perhaps you could ask its manufacturer to clarify why they don't accept a connection until they have received a fix, and why they stop transmitting data if a fix is lost? It's not transmitting anything at the point of turning on as it needs to boot up...
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 7.8K,
Visits: 8.4K
|
Yes, but this isn't 1980, surely the most it should take to "boot up" before a connection can be made to it (even if a fix isn't yet available, which is understandable) would be 30 seconds or something?
|
|
|
|
|
Lerk
|
|
|
Group: Forum Members
Posts: 19,
Visits: 0
|
+xYes, but this isn't 1980, surely the most it should take to "boot up" before a connection can be made to it (even if a fix isn't yet available, which is understandable) would be 30 seconds or something? Well my (admittedly 18 month old) iphone boots in just under 30 seconds and my apple watch (latest generation) just over 35 seconds. But by your own argument these would both still fail to meet the current 15 second timeout and that is before we consider the fact that I will have 'gone flying' selected 'log engine start' and actually started the engine before turning on the avionics master.
Given that you have a specific subset of your software dedicated to Pilotaware, can you not add an extended timeout (or at least an selectable option) to accomodate the startup delay of the 1980's raspberryPi?
|
|
|
|
|
pilot-byom
|
|
|
Group: Forum Members
Posts: 323,
Visits: 388
|
My 1980 computer devices boot much faster ... ‚modern‘ technology is far too fat, ugly, bad overloaded with garbage of suspicious quality ;-).
|
|
|
|
|
Tim Dawson
|
|
|
Group: Forum Members
Posts: 7.8K,
Visits: 8.4K
|
Lerk, the timeout is for when a connection has already been successfully established, and is very reasonable. I think you're asking for us to allow a connection to be made to a device which isn't yet alive, by the sound of it. I wonder what others are doing, as this doesn't seem to be a widespread problem. Could it be that others are powering on their device before the aircraft, giving it a chance to start?
|
|
|
|
|
Lerk
|
|
|
Group: Forum Members
Posts: 19,
Visits: 0
|
+xLerk, the timeout is for when a connection has already been successfully established, and is very reasonable. I think you're asking for us to allow a connection to be made to a device which isn't yet alive, by the sound of it. I wonder what others are doing, as this doesn't seem to be a widespread problem. Could it be that others are powering on their device before the aircraft, giving it a chance to start?
That's about the size of it Tim. Previously when renting aircraft, I had my PAW powered by a powerbank, so I plugged it in and booted it up as soon as I got to the aircraft - hence it had plenty of time to boot prior to starting the flight which might be anywhere up to a couple of minutes before logging engine start.
With the device connected to ships power, there is no way to boot the device prior to engine start. I might be sat with the engine warming up for 5 minutes before brakes off, so position isn't all that important for the initial portion of the log.
I could write down the engine start time manually and start the flight logging once the PAW has booted, but it seems a shame when your log summary captures all the necessary details as well as it does.
|
|
|
|
|
PaulSS
|
|
|
Group: Forum Members
Posts: 83,
Visits: 3.2K
|
"With the device connected to ships power, there is no way to boot the device prior to engine start."
Why is that, Lerk? If it's because your PAW is connected to an avionics bus, could you not just change that to the main bus instead, so that your PAW comes on with the Master Switch?
If you had your avionics bus connected to a pass-through battery and that battery plugged into your PAW I think that would work as well but you'd need a switch to turn the PAW on/off or else it would drain the pass-through battery if it were left on with no power from the avionics bus to recharge it.
I'm glad you created this thread though as it got me thinking. In my system design I have a Charge4 USB unit to supply the iPad, PAW etc and I previously had thought to have it on the avionics bus. It has been moved over to the main bus :-)
|
|
|
|