View Full Version : Information for all users of Flarm, OEM FLARM supplier and Flarm PowerFlarm
Hello Everybody
I worked for 20 years in ABB Deutschland and I have many colleagues who deal with electronic devices and GPS RF design.
We conducted a study on the operation of FLARM and the latest firmware release. I describe below what we found, and we hope that other competent can confirm our findings.
An Italian friend has translated this my description you will find at the end of the English version.
As is already well known to all users pilots, FLARM introducing the new coding xxtea present in the latest versions of firmware released, has largely complicated life to all of us and to itself.
With the new release the whole package of 24 bytes used for the data is encrypted (the length of the data packet is actually 32 bytes, but the first 8 bytes are left in clear because they include the name of the station as well as the meaning of the content of rest of the data packet ).
With this letter we want to bring to the attention of all users as well as the competent aeronautical authorities the weak points of this new solution, but especially the incredible risks to which this technical choice of Flarm is exposesing all of us. These risks were detected after very accurate tests performed in private laboratories in consequence to the release of the current firmware adopted. FLARM very hardly will admit the existence of these bugs and failures that we are exposing in detail.
The following data are explained in such a way so that people have the skills and the instruments can verify the truth of what is below reported.
This subject is independent from the Flarm decision to encrypt the protocol in order to protect themselves from potential and possible competitors.
It is obvious that the encryption has been introduced for this protectionist purpose, because from a merely technical point the integrity of the data transmission was already well protected by natively incorporated algorithms within the Nordic chip used in the Flarm hardware. For those that desire more technical information on this chip, is possible to click the following link http://www.nordicsemi.com/eng/content/download/2452/29528/file/Product_Specification_nRF905_v1.5.pdf
ALL manufacturers (except one) who claim to be "Flarm compatible" have inside EXACTLY the same hardware required by FLARM and they use the firmware released by FLARM (under payment of expensive license fee).
This behavior that we know from long time, is contrary to the principle of "development for competition" than in other fields has always given excellent results in technological development.
This behavior is especially contrary to the competition's principle that is mandatory by European rules for the sale of products to the public, it means that once people purchase products they should be functional and usable by the owner independently by firmware update. It's enough to think about Window as well as OS operating systems, that are fully compatible with earlier versions of software and operating systems used before.
But we want to come back to the description of the technical problems/issues , that is the main focus of this information.
The data package, which we have mentioned above, is broadcasted by FLARM units (it doesn't matter the licensed manufacturer) 2 times every second based on the internal clock of the GPS; the first transmission takes place in the first half of the "second", the second transmission in the second half.
For this reason, when the FLARM unit is receiving in RF (radio frequency) transmissions of FLARM installed on gliders nearby, and in addition these gliders are a lot, the available bandwidth in reception is saturated very quickly.
According to this situation when there are more traffic to be controlled/monitored, and thus the potential danger situations is increasing, the FLARM operates in the worst and most unreliable manner.
But unfortunally this is not the only technical problem source of malfunctioning . We've found a far more dangerous firmware bug we're going to detail below.
In order to complicate a possible decryption by third parties, the encryption key used by FLARM is not fixed anymore (as it was for the older version of the firmware) but is built with the code of the transmitting station and as well as with the GPS time of the first transmission moment ,and is changed every 64 seconds.
In addition to this during the 64 second interval, the data string transmitted change every second, because of the GPS position data updated is inside it.
The creator of the encryption code XXTEA says, and it is also reported by other cryptanalysts (see the articles by John Kelsey, Bruce Schneier, and David Wagner from 2002 to 2004), that exist certain combinations of DATA and KEYS in the encryption code XXTEA that, for some coding schemes, are producing results that WILL NOT BE PROPERLY decrypted also using THE CORRECT KEY.
This means in simple terms that there could be the possibility that some gliders nearby, whose code was not properly decoded , remain invisible to the system for at least 64 seconds, in other words until the next creation of the encryption key.
Of course it could happen the opposite case to be ourselves in the glider that at that moment is not properly decrypted by nearby gliders ; so we are invisible to others for at least 64 seconds.
This behavior has been detected with precise laboratory instruments by simply recording the exchange of data between three FLARM units for 48 hours.
Another unreliability detected comes from the fact that when a glider flies underneath thick clouds and is at high bank angles , may occasionally lose the connection to the GPS network. In this situation, the firmware should transmit only the last certain position detected by the GPS, waiting to transmit the new one as soon as the GPS hangs up the signal. The new version of the firmware without the GPS signal stops transmitting and receiving. It is easy to understand this by disconnecting the GPS antenna of a FLARM unit in operation and observing the lights that indicate the transmission and reception are turning off. Moreover , it is clearly understood by the evidence that a second FLARM device stops receiving the signal of the first device.
For the reason that the current firmware version in the absence of GPS signal stops transmitting and receiving, if ,at the time of losing GPS signal while change of encryption key , that glider will again be invisible for 64 seconds .
We report and highlight all this, a technical denial evidence based on irrefutable arguments, to loudly state that the decision of FLARM to encode the data packet using the encrypting code XXTEA, is generating flying situations that will put even more in danger OUR SAFETY, instead of protecting it, as it should be with the use of such a device.
At this point it is quite easy to say that the decision of FLARM is exclusively oriented to maintain an unlawful monopoly, for personal gain, in absolute disregard of the safety of FLARM users.
We affirm that is impossible to think the FLARM when issuing the new firmware version with the new encryption in March 2015, did not know what risks and unreliability exposed his system.
We say in all honesty that a collision avoidance system such as the one created by FLARM was certainly a great idea for the increased safety of pilots , but the search for more profit and the defense of its own unsustainable monopoly on the market through the continuous evolution of firmware only for protectionist purposes has brought today, with the latest firmware, to a situation in which this security is certainly not guaranteed, even though the FLARM devices are installed properly and working fine.
In light of these information, which we submit to the whole world of pilots, we wonder how could the relevant national and international aviation bodies (EASA first, then the French and other federations) push for the adoption of the current Flarm monopoly systems in everyday use and especially in competitions.
This information is therefore intended to attract interest for institutions, authorities and personalities involved in the flight's regulation , in order to arrive to the imposition of a public non-encrypted protocol.
This solution guarantee an excellent and reliable operation of FLARM units produced up to now, because no longer burdened by unnecessary decryption calculations, would guarantee in terms of competition the possibility of diversify the quality of the different vendors' solutions through different software developments management of traffic information received with the public protocol.
The aforementioned technical info are absolutely replicable and verifiable by anyone who has available the appropriate equipment and technical skills.
We hope with this letter ,we made a contribution to the safety growth of the flying community
Herbert Khum
ABB Deutschland
+41 43 317 71 22
On Thursday, March 3, 2016 at 9:26:47 AM UTC, wrote:
> Hello Everybody
> I worked for 20 years in ABB Deutschland and I have many colleagues who deal with electronic devices and GPS RF design.
> We conducted a study on the operation of FLARM and the latest firmware release. I describe below what we found, and we hope that other competent can confirm our findings.
> An Italian friend has translated this my description you will find at the end of the English version.
>
> As is already well known to all users pilots, FLARM introducing the new coding xxtea present in the latest versions of firmware released, has largely complicated life to all of us and to itself.
> With the new release the whole package of 24 bytes used for the data is encrypted (the length of the data packet is actually 32 bytes, but the first 8 bytes are left in clear because they include the name of the station as well as the meaning of the content of rest of the data packet ).
> With this letter we want to bring to the attention of all users as well as the competent aeronautical authorities the weak points of this new solution, but especially the incredible risks to which this technical choice of Flarm is exposesing all of us. These risks were detected after very accurate tests performed in private laboratories in consequence to the release of the current firmware adopted. FLARM very hardly will admit the existence of these bugs and failures that we are exposing in detail.
> The following data are explained in such a way so that people have the skills and the instruments can verify the truth of what is below reported.
> This subject is independent from the Flarm decision to encrypt the protocol in order to protect themselves from potential and possible competitors.
> It is obvious that the encryption has been introduced for this protectionist purpose, because from a merely technical point the integrity of the data transmission was already well protected by natively incorporated algorithms within the Nordic chip used in the Flarm hardware. For those that desire more technical information on this chip, is possible to click the following link http://www.nordicsemi.com/eng/content/download/2452/29528/file/Product_Specification_nRF905_v1.5.pdf
> ALL manufacturers (except one) who claim to be "Flarm compatible" have inside EXACTLY the same hardware required by FLARM and they use the firmware released by FLARM (under payment of expensive license fee).
> This behavior that we know from long time, is contrary to the principle of "development for competition" than in other fields has always given excellent results in technological development.
> This behavior is especially contrary to the competition's principle that is mandatory by European rules for the sale of products to the public, it means that once people purchase products they should be functional and usable by the owner independently by firmware update. It's enough to think about Window as well as OS operating systems, that are fully compatible with earlier versions of software and operating systems used before.
> But we want to come back to the description of the technical problems/issues , that is the main focus of this information.
> The data package, which we have mentioned above, is broadcasted by FLARM units (it doesn't matter the licensed manufacturer) 2 times every second based on the internal clock of the GPS; the first transmission takes place in the first half of the "second", the second transmission in the second half.
> For this reason, when the FLARM unit is receiving in RF (radio frequency) transmissions of FLARM installed on gliders nearby, and in addition these gliders are a lot, the available bandwidth in reception is saturated very quickly.
> According to this situation when there are more traffic to be controlled/monitored, and thus the potential danger situations is increasing, the FLARM operates in the worst and most unreliable manner.
> But unfortunally this is not the only technical problem source of malfunctioning . We've found a far more dangerous firmware bug we're going to detail below.
> In order to complicate a possible decryption by third parties, the encryption key used by FLARM is not fixed anymore (as it was for the older version of the firmware) but is built with the code of the transmitting station and as well as with the GPS time of the first transmission moment ,and is changed every 64 seconds.
> In addition to this during the 64 second interval, the data string transmitted change every second, because of the GPS position data updated is inside it.
> The creator of the encryption code XXTEA says, and it is also reported by other cryptanalysts (see the articles by John Kelsey, Bruce Schneier, and David Wagner from 2002 to 2004), that exist certain combinations of DATA and KEYS in the encryption code XXTEA that, for some coding schemes, are producing results that WILL NOT BE PROPERLY decrypted also using THE CORRECT KEY.
> This means in simple terms that there could be the possibility that some gliders nearby, whose code was not properly decoded , remain invisible to the system for at least 64 seconds, in other words until the next creation of the encryption key.
> Of course it could happen the opposite case to be ourselves in the glider that at that moment is not properly decrypted by nearby gliders ; so we are invisible to others for at least 64 seconds.
> This behavior has been detected with precise laboratory instruments by simply recording the exchange of data between three FLARM units for 48 hours.
> Another unreliability detected comes from the fact that when a glider flies underneath thick clouds and is at high bank angles , may occasionally lose the connection to the GPS network. In this situation, the firmware should transmit only the last certain position detected by the GPS, waiting to transmit the new one as soon as the GPS hangs up the signal. The new version of the firmware without the GPS signal stops transmitting and receiving. It is easy to understand this by disconnecting the GPS antenna of a FLARM unit in operation and observing the lights that indicate the transmission and reception are turning off. Moreover , it is clearly understood by the evidence that a second FLARM device stops receiving the signal of the first device.
> For the reason that the current firmware version in the absence of GPS signal stops transmitting and receiving, if ,at the time of losing GPS signal while change of encryption key , that glider will again be invisible for 64 seconds .
> We report and highlight all this, a technical denial evidence based on irrefutable arguments, to loudly state that the decision of FLARM to encode the data packet using the encrypting code XXTEA, is generating flying situations that will put even more in danger OUR SAFETY, instead of protecting it, as it should be with the use of such a device.
> At this point it is quite easy to say that the decision of FLARM is exclusively oriented to maintain an unlawful monopoly, for personal gain, in absolute disregard of the safety of FLARM users.
> We affirm that is impossible to think the FLARM when issuing the new firmware version with the new encryption in March 2015, did not know what risks and unreliability exposed his system.
> We say in all honesty that a collision avoidance system such as the one created by FLARM was certainly a great idea for the increased safety of pilots , but the search for more profit and the defense of its own unsustainable monopoly on the market through the continuous evolution of firmware only for protectionist purposes has brought today, with the latest firmware, to a situation in which this security is certainly not guaranteed, even though the FLARM devices are installed properly and working fine.
> In light of these information, which we submit to the whole world of pilots, we wonder how could the relevant national and international aviation bodies (EASA first, then the French and other federations) push for the adoption of the current Flarm monopoly systems in everyday use and especially in competitions.
> This information is therefore intended to attract interest for institutions, authorities and personalities involved in the flight's regulation , in order to arrive to the imposition of a public non-encrypted protocol.
> This solution guarantee an excellent and reliable operation of FLARM units produced up to now, because no longer burdened by unnecessary decryption calculations, would guarantee in terms of competition the possibility of diversify the quality of the different vendors' solutions through different software developments management of traffic information received with the public protocol.
> The aforementioned technical info are absolutely replicable and verifiable by anyone who has available the appropriate equipment and technical skills.
> We hope with this letter ,we made a contribution to the safety growth of the flying community
>
> Herbert Khum
> ABB Deutschland
> +41 43 317 71 22
I am not in a position to comment on the technical aspect of this posting but, as a technical note, it would carry a lot more weight in my mind if it were couched in less emotive terms.
John Galloway
Matt Herron Jr.
March 3rd 16, 03:18 PM
Herbert,
How many times in 48 hours did this 64 second dropout occur? Are you planning to publish your results and methods of testing?
Matt
jfitch
March 3rd 16, 04:02 PM
On Thursday, March 3, 2016 at 1:26:47 AM UTC-8, wrote:
> Hello Everybody
> I worked for 20 years in ABB Deutschland and I have many colleagues who deal with electronic devices and GPS RF design.
> We conducted a study on the operation of FLARM and the latest firmware release. I describe below what we found, and we hope that other competent can confirm our findings.
> An Italian friend has translated this my description you will find at the end of the English version.
>
> As is already well known to all users pilots, FLARM introducing the new coding xxtea present in the latest versions of firmware released, has largely complicated life to all of us and to itself.
> With the new release the whole package of 24 bytes used for the data is encrypted (the length of the data packet is actually 32 bytes, but the first 8 bytes are left in clear because they include the name of the station as well as the meaning of the content of rest of the data packet ).
> With this letter we want to bring to the attention of all users as well as the competent aeronautical authorities the weak points of this new solution, but especially the incredible risks to which this technical choice of Flarm is exposesing all of us. These risks were detected after very accurate tests performed in private laboratories in consequence to the release of the current firmware adopted. FLARM very hardly will admit the existence of these bugs and failures that we are exposing in detail.
> The following data are explained in such a way so that people have the skills and the instruments can verify the truth of what is below reported.
> This subject is independent from the Flarm decision to encrypt the protocol in order to protect themselves from potential and possible competitors.
> It is obvious that the encryption has been introduced for this protectionist purpose, because from a merely technical point the integrity of the data transmission was already well protected by natively incorporated algorithms within the Nordic chip used in the Flarm hardware. For those that desire more technical information on this chip, is possible to click the following link http://www.nordicsemi.com/eng/content/download/2452/29528/file/Product_Specification_nRF905_v1.5.pdf
> ALL manufacturers (except one) who claim to be "Flarm compatible" have inside EXACTLY the same hardware required by FLARM and they use the firmware released by FLARM (under payment of expensive license fee).
> This behavior that we know from long time, is contrary to the principle of "development for competition" than in other fields has always given excellent results in technological development.
> This behavior is especially contrary to the competition's principle that is mandatory by European rules for the sale of products to the public, it means that once people purchase products they should be functional and usable by the owner independently by firmware update. It's enough to think about Window as well as OS operating systems, that are fully compatible with earlier versions of software and operating systems used before.
> But we want to come back to the description of the technical problems/issues , that is the main focus of this information.
> The data package, which we have mentioned above, is broadcasted by FLARM units (it doesn't matter the licensed manufacturer) 2 times every second based on the internal clock of the GPS; the first transmission takes place in the first half of the "second", the second transmission in the second half.
> For this reason, when the FLARM unit is receiving in RF (radio frequency) transmissions of FLARM installed on gliders nearby, and in addition these gliders are a lot, the available bandwidth in reception is saturated very quickly.
> According to this situation when there are more traffic to be controlled/monitored, and thus the potential danger situations is increasing, the FLARM operates in the worst and most unreliable manner.
> But unfortunally this is not the only technical problem source of malfunctioning . We've found a far more dangerous firmware bug we're going to detail below.
> In order to complicate a possible decryption by third parties, the encryption key used by FLARM is not fixed anymore (as it was for the older version of the firmware) but is built with the code of the transmitting station and as well as with the GPS time of the first transmission moment ,and is changed every 64 seconds.
> In addition to this during the 64 second interval, the data string transmitted change every second, because of the GPS position data updated is inside it.
> The creator of the encryption code XXTEA says, and it is also reported by other cryptanalysts (see the articles by John Kelsey, Bruce Schneier, and David Wagner from 2002 to 2004), that exist certain combinations of DATA and KEYS in the encryption code XXTEA that, for some coding schemes, are producing results that WILL NOT BE PROPERLY decrypted also using THE CORRECT KEY.
> This means in simple terms that there could be the possibility that some gliders nearby, whose code was not properly decoded , remain invisible to the system for at least 64 seconds, in other words until the next creation of the encryption key.
> Of course it could happen the opposite case to be ourselves in the glider that at that moment is not properly decrypted by nearby gliders ; so we are invisible to others for at least 64 seconds.
> This behavior has been detected with precise laboratory instruments by simply recording the exchange of data between three FLARM units for 48 hours.
> Another unreliability detected comes from the fact that when a glider flies underneath thick clouds and is at high bank angles , may occasionally lose the connection to the GPS network. In this situation, the firmware should transmit only the last certain position detected by the GPS, waiting to transmit the new one as soon as the GPS hangs up the signal. The new version of the firmware without the GPS signal stops transmitting and receiving. It is easy to understand this by disconnecting the GPS antenna of a FLARM unit in operation and observing the lights that indicate the transmission and reception are turning off. Moreover , it is clearly understood by the evidence that a second FLARM device stops receiving the signal of the first device.
> For the reason that the current firmware version in the absence of GPS signal stops transmitting and receiving, if ,at the time of losing GPS signal while change of encryption key , that glider will again be invisible for 64 seconds .
> We report and highlight all this, a technical denial evidence based on irrefutable arguments, to loudly state that the decision of FLARM to encode the data packet using the encrypting code XXTEA, is generating flying situations that will put even more in danger OUR SAFETY, instead of protecting it, as it should be with the use of such a device.
> At this point it is quite easy to say that the decision of FLARM is exclusively oriented to maintain an unlawful monopoly, for personal gain, in absolute disregard of the safety of FLARM users.
> We affirm that is impossible to think the FLARM when issuing the new firmware version with the new encryption in March 2015, did not know what risks and unreliability exposed his system.
> We say in all honesty that a collision avoidance system such as the one created by FLARM was certainly a great idea for the increased safety of pilots , but the search for more profit and the defense of its own unsustainable monopoly on the market through the continuous evolution of firmware only for protectionist purposes has brought today, with the latest firmware, to a situation in which this security is certainly not guaranteed, even though the FLARM devices are installed properly and working fine.
> In light of these information, which we submit to the whole world of pilots, we wonder how could the relevant national and international aviation bodies (EASA first, then the French and other federations) push for the adoption of the current Flarm monopoly systems in everyday use and especially in competitions.
> This information is therefore intended to attract interest for institutions, authorities and personalities involved in the flight's regulation , in order to arrive to the imposition of a public non-encrypted protocol.
> This solution guarantee an excellent and reliable operation of FLARM units produced up to now, because no longer burdened by unnecessary decryption calculations, would guarantee in terms of competition the possibility of diversify the quality of the different vendors' solutions through different software developments management of traffic information received with the public protocol.
> The aforementioned technical info are absolutely replicable and verifiable by anyone who has available the appropriate equipment and technical skills.
> We hope with this letter ,we made a contribution to the safety growth of the flying community
>
> Herbert Khum
> ABB Deutschland
> +41 43 317 71 22
"It's enough to think about Window as well as OS operating systems, that are fully compatible with earlier versions of software and operating systems used before. "
Well that is particularly bad example. If Flarm becomes as unreliable as the Windows operating system, we are all doomed.
If the development of Flarm firmware is opened up to any and all, we risk that not just one glider, but a whole network will be brought down. I can't see that as an improvement in safety. When you can buy a clone Flarm on Alibaba for 30 Euro, who's life will you be putting at risk beyond your own? Believe me, it will not work properly. If open to all, like other aviation instruments, there will need to be government certification, and that will make the price much higher, not much lower.
I have no financial stake in Flarm, the equipment is high priced compared to (multi million unit) consumer sales, but not at all out of line for glider panel instruments. It occurs to me that those accusing them of profiteering are themselves motivated by profit - they wish to capitalize on the device and market created by Flarm, without the engineering and marketing effort.
As a technical comment, it seems to me that is it better not to transmit an erroneous position in the event of a GPS dropout, than to go on transmitting a false one.
One must always remember than Flarm is not an insurance policy, merely one instrument to assist the pilot in flying safely. Expecting absolute reliability of it, or any instrument, will get you killed someday.
Ditto what jfilch says. Flarm while slightly helpfull can, in my opinion, lead one into a false sense of security which creates more of a dangerous situation than it is suppossed to mitigate. I trust my eyes not the gadget that may or maynot indicate someone around, and I sure as hell dont want the feds mandating that I need another chunk of electronics installed in my bird.
Tango Whisky
March 3rd 16, 04:25 PM
> Herbert Khum
> ABB Deutschland
> +41 43 317 71 22
I'm a little puzzled why ABB Capital would get involved in this,
Bert
Ventus cM "TW"
On Thursday, March 3, 2016 at 10:25:40 AM UTC-6, Tango Whisky wrote:
> > Herbert Khum
> > ABB Deutschland
> > +41 43 317 71 22
>
> I'm a little puzzled why ABB Capital would get involved in this,
>
> Bert
> Ventus cM "TW"
Bert, I'm sure ABB has nothing to do with the matter. He is just fishing for credibility.
Darryl Ramm
March 3rd 16, 06:05 PM
On Thursday, March 3, 2016 at 9:32:57 AM UTC-8, wrote:
> On Thursday, March 3, 2016 at 10:25:40 AM UTC-6, Tango Whisky wrote:
> > > Herbert Khum
> > > ABB Deutschland
> > > +41 43 317 71 22
> >
> > I'm a little puzzled why ABB Capital would get involved in this,
> >
> > Bert
> > Ventus cM "TW"
>
> Bert, I'm sure ABB has nothing to do with the matter. He is just fishing for credibility.
And he does not seem to know which county he is in, Germany or Switzerland (+41 country code).
There are already some "personalities" involved here no doubt.
I'll wait for more info on the alleged technical problem. As for the attitude that "FLARM risked time and money to develop a proprietary technology that a lot of pilots want and now that it's successful, we don't think it's fair unless it's shared" (translation: from each according to his ability, to each according to his needs), until such time as Bernie dispatches Hillary and then the Donald, I have no problem with this kind of "monopoly", at least in the U.S.
Chip Bearden
Dan Marotta
March 3rd 16, 08:25 PM
As a (retired) systems engineer, I read the analysis on strictly
technical terms, no worries about personalities, profits, fixed costs or
any other possible motivations. I only saw the /_possibility_/ of 64
second dropouts, not the certainty. I saw no denigration of the
efficacy of Flarm in its intended role, only that the encryption of its
transmissions could /_possibly_/ result in erroneous position
reporting. Maybe the author would have been better received had he left
out the talk about monopolies, etc.
It is my understanding that the reason for Flarm signals to be encrypted
was to thwart a rogue group of Brits (tongue deeply in cheek) from using
a network of cheap receivers to receive and process Flarm signals to
post the locations of the gliders on a webpage for them to track the
progress of the gliders in flight. And if I'm correct in that
recollection, isn't that what the other sailplane trackers currently
do? Not necessarily using Flarm signals, but some other means to
display the locations and tracks of gliders.
On 3/3/2016 12:18 PM, wrote:
> I'll wait for more info on the alleged technical problem. As for the attitude that "FLARM risked time and money to develop a proprietary technology that a lot of pilots want and now that it's successful, we don't think it's fair unless it's shared" (translation: from each according to his ability, to each according to his needs), until such time as Bernie dispatches Hillary and then the Donald, I have no problem with this kind of "monopoly", at least in the U.S.
>
> Chip Bearden
--
Dan, 5J
jfitch
March 3rd 16, 11:10 PM
On Thursday, March 3, 2016 at 12:25:43 PM UTC-8, Dan Marotta wrote:
> As a (retired) systems engineer, I read the analysis on strictly
> technical terms, no worries about personalities, profits, fixed
> costs or any other possible motivations.* I only saw the possibility
> of 64 second dropouts, not the certainty.* I saw no denigration of
> the efficacy of Flarm in its intended role, only that the encryption
> of its transmissions could possibly result in
> erroneous position reporting.* Maybe the author would have been
> better received had he left out the talk about monopolies, etc.
>
>
>
> It is my understanding that the reason for Flarm signals to be
> encrypted was to thwart a rogue group of Brits (tongue deeply in
> cheek) from using a network of cheap receivers to receive and
> process Flarm signals to post the locations of the gliders on a
> webpage for them to track the progress of the gliders in flight.*
> And if I'm correct in that recollection, isn't that what the other
> sailplane trackers currently do?* Not necessarily using Flarm
> signals, but some other means to display the locations and tracks of
> gliders.
>
>
>
>
> On 3/3/2016 12:18 PM,
> wrote:
>
>
>
> I'll wait for more info on the alleged technical problem. As for the attitude that "FLARM risked time and money to develop a proprietary technology that a lot of pilots want and now that it's successful, we don't think it's fair unless it's shared" (translation: from each according to his ability, to each according to his needs), until such time as Bernie dispatches Hillary and then the Donald, I have no problem with this kind of "monopoly", at least in the U.S.
>
> Chip Bearden
>
>
>
>
>
> --
>
> Dan, 5J
My reading of it isn't that it transmits erroneous positions (which would be bad) but that it does not transmit positions at all, or the transmissions that it makes cannot be decrypted and would be ignored. In other words the same situation as if that particular glider had no Flarm. In the US anyway, many don't, you better be looking for them anyway!!!
Martin Gregorie[_5_]
March 4th 16, 12:24 AM
On Thu, 03 Mar 2016 13:25:31 -0700, Dan Marotta wrote:
> It is my understanding that the reason for Flarm signals to be encrypted
> was to thwart a rogue group of Brits (tongue deeply in cheek) from using
> a network of cheap receivers to receive and process Flarm signals to
> post the locations of the gliders on a webpage for them to track the
> progress of the gliders in flight. And if I'm correct in that
> recollection, isn't that what the other sailplane trackers currently do?
> Not necessarily using Flarm signals, but some other means to display
> the locations and tracks of gliders.
>
I thought they were a German group, but I digress and could be wrong. I
don't recall any FLARM users objecting to them building ground-based
FLARM receivers and using them to track gliders, indeed this was seen as
a useful service throughout Europe, PROVIDED that they obeyed the pilot's
wishes and did not publish identification data for gliders using stealth
mode. However, there were some hardline 'all data is free' fanatics in
the group who refused to play nice with stealthed gliders and so FLARM
encrypted the messages to make them behave.
At least, thats why I remember encryption was introduced: it had
absolutely nothing to do with commercial secrets or anybody getting rich
and everything to do with third parties violating another's privacy.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
This thread was interesting for about 64 seconds...and then the moment passed.
On Friday, 4 March 2016 01:58:04 UTC+1, wrote:
> This thread was interesting for about 64 seconds...and then the moment passed.
Head on!
smfidler
March 4th 16, 04:48 AM
Ban it?
Ramy[_2_]
March 4th 16, 06:55 AM
My eyes hurt trying to read all this. Can someone write an executive summary of the issue and concern for the rest of us?
Ramy
Darryl Ramm
March 4th 16, 07:43 AM
Ramy
I could summarize the bizarre aforementioned pontification, but I would need to encrypt that summary.
Darryl
Pat Russell[_2_]
March 4th 16, 12:21 PM
FAI/IGC seem to have punted on the encryption question.
Tim Newport-Peace[_2_]
March 4th 16, 12:58 PM
At 12:21 04 March 2016, Pat Russell wrote:
>FAI/IGC seem to have punted on the encryption question.
>
As far as I as aware, the only envolvement IGC have with Flarm is as an
Approved Flight Recorder, which is not affected.
In other matters I believe IGC do not approve or disapprove, nor do they
specify.
Alex[_6_]
March 4th 16, 02:20 PM
> In other matters I believe IGC do not approve or disapprove, nor do they
> specify.
The IGC ANDS committee disapproves of the current FLARM position. I am not sure if this has yet evolved to be the official IGC position on the topic.
http://www.fai.org/downloads/igc/IGC_2016_Plenary_AX6_2_4
Personally, I don't share the opinion of the ANDS committee
jfitch
March 4th 16, 04:50 PM
On Friday, March 4, 2016 at 6:20:29 AM UTC-8, Alex wrote:
> > In other matters I believe IGC do not approve or disapprove, nor do they
> > specify.
>
> The IGC ANDS committee disapproves of the current FLARM position. I am not sure if this has yet evolved to be the official IGC position on the topic.
>
> http://www.fai.org/downloads/igc/IGC_2016_Plenary_AX6_2_4
>
> Personally, I don't share the opinion of the ANDS committee
I would say the ANDS committee questions the Flarm position. They do not offer any alternative, nor do they approve of the alternatives offered by others.
Cue the singing Vikings!
Jim
Bob Pasker
March 4th 16, 05:32 PM
Hi -- can you please provide an exact citation for this? --bob
"The creator of the encryption code XXTEA says, and it is also reported by other cryptanalysts (see the articles by John Kelsey, Bruce Schneier, and David Wagner from 2002 to 2004), that exist certain combinations of DATA and KEYS in the encryption code XXTEA that, for some coding schemes, are producing results that WILL NOT BE PROPERLY decrypted also using THE CORRECT KEY. "
In five years time we're all going to be fitting ADS-B anyway. Flarm could have been at the forefront of that movement, which would have leveraged their valuable IP relating to flight path prediction, but they appear to have squandered the opportunity by instead fighting a rearguard action to protect their RF protocol.
My subjective impression of the latest Flarm software version is that it is not as reliable as it was, and range is reduced. But I have no hard data to confirm that.
Stu
March 10th 16, 06:25 AM
Yesterday two of us flew after updating our Flarms with the latest software.. We were careful to leave the Config files as they were when we flew last year. The Flarm range analyzer showed the range of the latest software to be only 3 km while the range of our flights last year were 6 km. Have others experienced this same result? If so, is there a fix to get the range back to were it was under the previous software?
Stu Larimore
2Z
Nick Hill[_3_]
March 11th 16, 10:53 AM
On 10/03/2016 06:25, Stu wrote:
>Yesterday two of us flew after updating our Flarms with the latest software.
>We were careful to leave the Config files as they were when we flew
last year.
>The Flarm range analyzer showed the range of the latest software to be
only 3 km
>while the range of our flights last year were 6 km. Have others
experienced this
>same result? If so, is there a fix to get the range back to were it
was under the
>previous software?
>
> Stu Larimore
> 2Z
>
The Flarm config doc available here
http://flarm.com/wp-content/uploads/2015/12/FTD-14-FLARM-Configuration-Specification-1.03.pdf
Describes the general setting:
RANGE: Sets maximum horizontal distance of received aircraft
I don't know if the config setting for RANGE also applies to Flarm
contact data recorded in the IGC trace. The default for RANGE if you
don't set it is 3Km for Classic Flarm. This limits the range of any
target on external displays.
The IGC trace from a flarm will have recorded the setting for this
parameter, look for something like
LFLA13502607RANGE 3000
--
Nick Hill
Surge
March 11th 16, 11:19 AM
On Friday, 11 March 2016 12:53:11 UTC+2, Nick Hill wrote:
> The default for RANGE if you
> don't set it is 3Km for Classic Flarm. This limits the range of any
> target on external displays.
I don't see 3km mentioned in that FLARM specification.
It specifies that the default horizontal range is 25500 meters for classic FLARM and 65535 meters for PowerFLARM.
Default vertical range is 500 meters for all FLARM device types.
Nick Hill[_3_]
March 11th 16, 05:24 PM
On 11/03/2016 11:19, Surge wrote:
> On Friday, 11 March 2016 12:53:11 UTC+2, Nick Hill wrote:
>> The default for RANGE if you
>> don't set it is 3Km for Classic Flarm. This limits the range of any
>> target on external displays.
>
> I don't see 3km mentioned in that FLARM specification.
> It specifies that the default horizontal range is 25500 meters for classic FLARM and 65535 meters for PowerFLARM.
> Default vertical range is 500 meters for all FLARM device types.
>
The've updated it! I had version 1.02 on my PC whch is what I looked at
but sent the link to the website one which is v 1.03.
Should have read the version control on page one which says in V1.03
"Changed Classic FLARM default range"
Worth checking that the IGC file reflects the RANGE value as in the doc.
--
Nick Hill
Brian[_1_]
March 12th 16, 04:31 AM
Thanks Nick,
I didn't realize the range data was saved in the IGC file.
I just checked Stuart's file, his is set to 20000.
So something else must have changed.
I looked at some of his previous files and the range tool show ranged of 5-6km. This years flight with the new firmware only shows about 3km on the range tool. We were very carefull not to change the configuration only updated the firmware.
Brian
V6
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.