Post the question on the Skydemon user forum….Tim or someone will answer you….but u would try deleting and reinstalling the app first…
Sounds to me like it is getting a marginal mobile data connection, which is fairly obviously going to happen when flying!
One would think the program would not be alerting to this kind of thing, however. It should be silently recovering / retrying.
Posting it here is a good thing because there are many SD users here.
I’ve never seen that though….you either get a rush of updates or nothing…presumably the signal is going from ok to weak to zilch and back all the time…
I get the same errors when flying with Skydemon. Best is to turn your mobile data off before flight.
I agree with Peter that SD should ignore parsing errors on partially downloaded NOTAMS / METAR during flight.
This must be a real challenge.
I have a lot of “experience” testing GSM/3G/4G data in flight. The behaviour varies dramatically. The worst thing is that you could easily get half a TAF and since there is no checksum you would never know. Most tafs/metars will fit wholly inside a single TCP/IP packet (so will be delivered to the app whole or not at all) but in many scenarios they will be split up and then you could get just a part of it.
EGKK 221105Z 2212/2318 30008KT 9999 FEW013 BKN030 TEMPO 2212/2214 5000 RA -RADZ BKN012
is not the same as
EGKK 221105Z 2212/2318 30008KT 9999 FEW013 BKN030 TEMPO 2212/2214 5000 RA -RADZ BKN012 BECMG 2218/2221 CAVOK PROB40 TEMPO 2308/2311 BKN012
It’s not obvious how one would detect this, however.
The only sure way would be to run a server which packages the data with checksums or whatever, and the mobile app accesses that server.
Another way (if SD gets the data from the usual source i.e. the ADDS/NOAA website and not going via an SD-run server, IOW it is just accessing a web page) would be to look for the end of the ADDS web page (e.g. < / head > ) but then you could still get corruption within the web page.
A lot of mobile apps go straight to the ADDS website. This is obvious because whenever ADDS change the layout, these apps break 
For example a while ago they added a fontspec to the TAF line, and it broke most apps out there until they were updated…
AnthonyQ wrote:
Post the question on the Skydemon user forum
Did so, no answer yet.
Peter wrote:
This must be a real challenge.
Those guys have solved much more difficult issues, this should be a no-brainer to find a solution to (you already gave one in your answer with an intermediate server). Bothering the pilot with half a page of red messages is definitely not the best option.
Sky Demon keeps retrying by itsel.
My advice – ignore error and wait for a message flashing in the middle of the screen saying that an airfield or airfields TAF or METAR has/have updated. The problem isn’t of Sky Demon’s making it’s a communication error.
Here is the answer from SkyDemon:
It sounds like your problem could be related to poor 3G/4G data coverage when you’re airborne. It could be the case that your 3G connection is a little unreliable, so SkyDemon is trying and failing to complete the downloads. Alternatively, your 3G data provider might need you to validate your connection or log in via your web browser before you can properly use your cellular data, so I would recommend opening Safari on your iPad when you’re using cellular data (not when you’re on wifi) to see if you’re being prompted to log in or complete some other activation steps.
You can always switch the SkyDemon app so that it’s offline when you’re in Go Flying mode, which means it would not be trying (and failing) to get live updates. You’ll find the option to set the app to receive live data when planning only in the Setup > Connectivity Options menu.
While I understand the technical problem, I still prefer flying with the connection on, so that I can get an update in the case when there is reliable signal. So I suggested to SD to show this only as a warning (e.g. “TAF/METAR may not be current”) instead of showing so many red messages.
your problem could be related to poor 3G/4G data coverage when you’re airborne
Surely that cannot be the answer?
So I suggested to SD to show this only as a warning (e.g. “TAF/METAR may not be current”)
But, they cannot know that unless they somehow wrap up the whole session inside an error detecting wrapper.
If you just hit a normal website with a client device running some code which parses HTML, you cannot ever know you got all of it, or some of it. Well, not unless the entire return data block fits inside a single TCP/IP packet and you can ensure that always happens.
This is an interesting challenge.
Achim’s telegram based wx delivery service works (or doesn’t work at all) because, presumably, Telegram sends the whole message as one atomic session.
Peter wrote:
they cannot know that
They obviously know that something went wrong while receiving some kind of data (e.g. METAR), so they can immediately say: OK, from this moment on METAR is not reliable → mark it yellow. It’s like expired – you don’t know the new value but know your current one is probably not valid any more. It’s only a visualization suggestion from my side.
Yours is more complex and also better in the long run but also probably more difficult to implement so unless a lot of users complain it probably won’t bubble up to the top of the work items list.
