I use a prepaid Vodafone simcard ( 30days/ 200mb/ 4,95€ ) and IIRC only get these corrupt data when I’m over the 30days period the simcard is valid for …
It is not a SD fault but a failed data provider connection.
BTW you see on the SkyDemon Metar/ TAF menu how old these reports are.
Peter wrote:
It’s not obvious how one would detect this, however.
Don’t METAR and TAF messages always end with a = character, normally not found anywhere else in the message itself? That would take care of the truncated message situation. Other corruptions may, of course, still go unnoticed. But in this case the app actually seems to be able to detect the corruption, just displays it inapropriately.
nobbi wrote:
It is not a SD fault but a failed data provider connection.
All agree that it is not the fault of SkyDemon, but it is a poor decision to display these error messages in such prominent way, actually obstructing the use of the app. At work we are developing a mobile app that can mostly work offline, but have some features, which require internet connection. If there is a connection error and the user tries to use one of those features, we of course display a well visible erorr message, but one carefully designed not to hinder the use of offline functions.
only get these corrupt data when I’m over the 30days period the simcard is valid for
That is a very good point, because I have found that SIMs which have “expired”, or ones which need some additional action to work on say mobile data, do actually transfer some very limited amounts of data anyway. I believe this feature was implemented because many devices (smartphones, originally IOS but nowadays android too) use mobile data for many non-obvious functions such as GPS enhancement (look up SUPL and Assisted GPS), as well as sending little bits of data back to “the church”. I have demonstrated that many times.
This could catch out an app which sends and receives very small packets.
Don’t METAR and TAF messages always end with a = character,
Not at the “usual place” where most free wx services get it from
nobbi wrote:
IIRC only get these corrupt data when I’m over the 30days period the simcard is valid for
I am on my standard contract (no expiration or limits) and on the ground in this case, so it is more probable that it is a problem with the signal being blocked by metal structures around and/or no close by antenna.
At the risk of asking the obvious, what happens if you are on 3G/4G at home?
Vladimir, I now remember that I got those corrupt data also when my mini i-pad logged on with Vodafone in Avignon / France ( my SimCard only valid within Germany ).
Could it be that, while everything worked well on the ground, you take off in ZRH and in the air your device logs in a German station without having roaming activated?
Why don’t other apps and websites suffer the same problem?
Generally if you don’t get the full message with IP comms, you know that you haven’t got the full message. You can either give a “failed” message or try it again. You wouldn’t normally try to parse a failed download. Must be something else going on.
Peter wrote:
Not at the “usual place” where most free wx services get it from
The character to look for in this case would be called carriage return and/or line feed 
If you look at the HTML actually returned
there is no CRLF; you might perhaps look for the bit I marked in yellow.
Or is there a CRLF after the FEW016? I thought HTML was just a stream. But this all just illustrates how flakey this kind of stuff is. When ADDS added the FONT FACE= bit, most weather apps stopped working until updates were rolled out.
Generally if you don’t get the full message with IP comms, you know that you haven’t got the full message. You can either give a “failed” message or try it again. You wouldn’t normally try to parse a failed download. Must be something else going on.
I don’t think a browser ever knows the end of data. The end of data becomes “obvious” in the above case with the receipt of the closing < / HTML > line, but nothing prevents more data arriving which the browser will still display.
Obviously anything can be done to validate the data, but you have to make assumptions about what is coming back, and if you are on a bad connection and you are not using a dedicated server which wraps the whole lot inside some sort of wrapper, you could have fun.
When airborne, you get a sequence of complete disconnects, each one being sudden and undetectable (the data simply stops flowing) so only a timeout will help, and then you get a fresh DHCP exchange and a fresh IP connection, until it again breaks some seconds later. Couple this with the connection being any of GPRS to 4G (a range of speeds from c. 10kbits/sec to c. 10Mbits/sec) and the mobile device auto switching between these without the app being told which speed to expect which makes simple timeouts a very bad way to do it…
Nobody has solved this successfully, despite getting solid data over constantly breaking connections being such an obvious holy grail in so many applications outside GA. Look at how badly mobile devices deal with broken connections…
nobbi wrote:
Could it be that, while everything worked well on the ground, you take off in ZRH and in the air your device logs in a German station without having roaming activated?
As you can see on the screenshot, I am still on the ground at the runup location. Zurich is not that close to Germany and I don’t get German signal on the ground here.
