In recent discussions on Futaba and FrSky threads several posters have mentioned upcoming changes to the EU standards for 2.4GHz equipment (see references below). Based on these posts I have done some research of my own, and found out the following information so far:

• A revised version of the ETSI standard EN 300 328 (v1.8.1) has been published and will come into force in Jan 1st 2015.
• Version 1.8.1 has an effective date of December 31, 2014, so declarations of conformity with the Radio and Telecommunication Terminal Equipment (R&TTE) Directive based on testing against EN 300 328, v1.7.1 would need to be re-evaluated before the end of 2014 for devices going into the EU market after this date. Devices already in the market will be grandfathered in. However, at the same time as the v1.8.1 adoption, a note was added to v1.7.1 in the EU's Official Journal (OJ), stating that part of the new v1.8.1 requirements – medium utilization factors – needed to be immediately implemented and tested.
  The upshot: Radio modules tested and found compliant to v1.7.1 need to be retested due to the additional requirement – there is no longer a presumption of conformity with the R&TTE Directive. This has caused confusion and headache for manufacturers and some test labs. (Source)
• V1.8.1 made significant changes to the requirements and test procedures used in the previous version. EIRP measurements now have to account for beamforming gain, if supported by the product. A major change was the flushing out of the test procedure for the Medium Access Protocol requirement. In past versions of the standard, how to comply with the Medium Access Protocol requirement was undefined. This is no longer the case. Devices that wish to operate with more than 10dBm eirp, and are not adaptive (able to adapt to its environment by identifying other transmissions present in the band) are subject to new timing requirements. Devices that are adaptive now must prove compliance using the procedures in v1.8.1. (Source)
• Summary of significant changes for existing products: (Source)
  RF output power – new test procedure, limit remains unchanged. The new procedure requires equipment that isn’t currently readily available, especially for multichain transmitters.
  Power Spectral Density – new test procedure, limit remains unchanged. Similar to the power measurements, the ability to perform the test in strict accordance with the procedure will be limited in the near term.
  Transmitter Spurious Emissions – This requirement has been broken up into two separate tests; Transmitter unwanted emissions in the out-of-band domain (OOB) and Transmitter unwanted emissions in the spurious domain. For the OOB requirement, a mask is applied that extends out 2 bandwidths away from the 2400-2483.5MHz band. This is a new requirement that is to be performed over extreme conditions. The spurious domain requirement has updated the limits and test procedure to be consistent with EN 301 893.
  Frequency Range – The test procedure has changed to use a 99% bandwidth measurement, and to be performed only at nominal conditions.
  Medium Access – As mentioned before, adaptive and non-adaptive devices operating at more than 10dBm eirp, are now subject to new timing restrictions. In addition, adaptive equipment will need to be able detect noise and cease transmission. A greater understanding of the transmission protocol is required to execute these tests.
• Conclusion (Source):
  Manufacturers should be planning on moving to v1.8.1 of EN 300 328. Given the DOW, end of 2014, there is a reasonable change that another revision could be released and adopted before that date. Therefore, updating any current devices or projects would not be recommended till closer to the end of 2014. In the mean time, [manufacturers] reviewing the medium access requirements and their applicability to their products is strongly encouraged.

Existing posts on this subject:

• Possible non-compliance of Futaba FASST with v1.8.1
• Possible non-compliance of FrSky ACCST with v1.8.1 (suggests that only the latest Aurora 9X and DSMX comply with the new standard in their current form, but that some systems will be firmware upgradeable to meet the standard)
• Follow up post in FrSky thread - confirms only gear sold after 1st Jan 2015 will need to comply

Caveat - I am no expert in RF, hence why I have quoted the above sources verbatim, but I am interested in understanding this issue and it's impact on me and all RC users in the EU. I know there are lots of more knowledgeable people here that may be able to contribute valuable information re: this change.

Aim of this thread:
To discuss this change and understand the impact of the change on users of all the major 2.4GHz RC manufacturers, specifically:

• Which protocols do and do not comply with the ETSI standard EN 300 328 (v1.8.1) at present?
• Of those that don't, which can be updated to comply in future?
• Are there any TXs/modules/RF protocols that will no longer be sold in the EU as a result of this change?
• Over time we may also be able to capture a set of links to resources for those needing to complete software updates on their RC gear (probably not until late 2014/early 2015 though).

Since this issue will probably affect users of every RC manufacturer in 2015, please don't let this slide into an "x is better than y" conversation - it doesn't add any value. Just post up any information you have that moves forward our understanding, and hopefully we can quickly build a picture of whether this will be a major issue or a minor hiccup. Many thanks!

Update Dec 14 - Futaba have issued a firmware update for the 14SG to ensure it complies with the new regs for 2015. As a by product it appears the FrSky FASST RXs and some Simprop RXs no longer work correctly; reason is currently unknown (even some Futaba RXs seem to have lost a degree of performance and are showing dropped frames as is logically expected). Presumably similar updates are also on their way for the other FASST TXs in the range before end Dec?

From the 14SG thread...

Originally Posted by Harri Pihl

Edit: 6th December 2014:
WARNING: The V5 firmaware update from December 2014 contains FASST protocal changes for the european region coded 14SG/FX-22 transmitters to comply new EU rules (listen before transmit). After the update the non Futaba made FASST compatible receivers might lose the link. Users have reported this problem with the FrSky TFR6 receiver and this probably affects also other FrSky FASST combatible receivers as well as rebranded versions. It's possible that the problem also affects other FASST compatible receivers like Simprop, Corona, Orange etc. The problem affects only the european region coced 14SG/FX-22. The region can be checked from SYSTEM -> INFO -> AREA menu.

Edit: 7th December 2014:
WARNING: The V5 firmware problem has been reported also with the Simprop Gigascan FASST compatible receivers.

Additional resources/posts of note since this thread was started:

• A great post on how FHSS hopping is synced between TX and RX.
• Confirmation that DSM2 does not comply with the new regs and will no longer be sold in the EU.
• FrSky have released updated firmware for the Taranis, XJT module and all X series RXs; however it now appears D-series RXs are no longer compliant, and will no longer be sold in the EU.
• Sept 2015 - Some "interesting" news on revised regulations in the EU and US around the firmware used in RF transmitting devices - looks like flashing whichever RF firmware you fancy will no longer be possible in the EU from June 2016 and in the US from a date tbc...
• Jan 2016 - An interesting thread on the use of FrSky's D8 mode moving forward in the EU...

Current (Aug 2015) summary by brand...

• Spektrum DSM2 – New Spektrum TXs sold from now on will not transmit DSM2 in the EU, which is not compliant with the new regs. Since all Spek RXs sold have been DSMX for some time, should not have any effect on current users unless you have a stack of old DSM2 only RXs and want a new TX. Workaround – hoard your old Spek DSM2 TX, or buy a Taranis and buy an OrangeRX DSM2/X module from Hobbyking.
• Futaba FASST & FHSS – FASST definitely was not compliant; opinions vary on whether the S/T-FHSS protocols were or not. Either way, Futaba have released firmware updates for the two current FASST sets on sale in the UK (14SG and 18MZ), and documentation indicates changes were made to the RF firmware for all three protocols. These changes seem to work ok with genuine Futaba RXs, but the reverse engineered FASST RXs from FrSky and others now do not work with the upgraded TXs. FrSky have now released updated firmware for their FASST RXs that addresses the issue.
• FrSky ACCST – New firmware has been released for the X-series RXs, XJT module and Taranis TX. Existing X series will not work with an upgraded TX, and new X-series RXs will not work with a Taranis that has not been upgraded to the new firmware. D series and V8 (non telemetry) RXs seem unaffected and work with an upgraded TX without any changes; no D/V8 RX firmware updates released as yet, and currently it appears none will be, meaning they will no longer be sold in the EU. EDIT January 2016 - FrSky release revised EU firmware based on LBT , plus an interesting thread on the use of FrSky's D8 mode moving forward in the EU...
• Hitec AFHSS, Jeti Duplex, JR DMSS, Spektrum DSMX – Already compliant with new regs; no action required.
• Graupner HoTT – Initially believed to be compliant, but then questions were raised; has remained on sale though without changes so must be compliant.
• Multiplex M-Link – Unknown, but there seems to be little buzz online about non-compliance and Multiplex were deliberately late to launch their 2.4 offering due to uncertainty about the regs, so likely to already comply.

Our stuff is all 'adaptive' so the new timing requirement won't apply. However the 'cease transmission' part for both adaptive and non-adaptive is very strange. They rely on successfully 'bouncing off each other' to work at all. That might have been part of Spektrum's DSM2 problem.

As for the rest, it appears to be about more testing or additional testing where none was previously required.. They may not need to change most of the stuff at all.

Not all systems are adaptive, or we understand different the term.

I mean if someone come to your field and start a FPV VTx in 2.4GHz band, which will eat about 1/4 of available band, all the systems will continue to hop using channels in the VTx band, (and failing when doing this), only Hitec AFHSS will reshape his channels distribution to avoid the new "enemy" territory.
This adaptability has been emphasized by Bruce in his AFHSS review, is on youtube too.

Originally Posted by renatoa

only Hitec AFHSS will reshape his channels distribution to avoid the new "enemy" territory.

This only applies to the original Scan mode in A-FHSS. The original scan mode was discontinued in v3 of the 2.4GHz Spectra Module firmware a couple of years ago now. Hitec A-FHSS operates in the same way as other FHSS system do now - except with the one feature of the 'new' scan mode. This new scan mode is probably better named as re-tune mode. Upon activating it, it will scan the band and pick channels that have the least noise/traffic.

However picking these new channels will invalidate all the bind settings in all your hitec receivers. So you have to rebind all your receivers to pick these new channels up, otherwise you'll get a broken plane. To be honest, unless your flying site is suffering from terrific interference on the 2.4GHz band (which given most flying fields are in the middle of a field, not many sites), it doesn't have much use for most users.

Si.

A great post from Si on the "Futaba 10J - the end of FASST?" thread....

Originally Posted by SimonChambers

RC Receivers knows what channels to use before it gets the first data packet from the RC transmitter. The channel hop pattern doesn't ever change once the transmitter and receiver are in sync. A channel hop is done on a particular time slot. So for example, FrSky system hop to another channel every 9ms, Hitec A-FHSS every 21ms, etc, etc.

I've seen two methods of how the receiver determining the channel hop patterns:

1. During Binding the transmitter will share the channels to use and what order they are in. Some protocols literally send the channel numbers to use. Others use a code that is used in a mathmatical operation to determine the channels and hop pattern.
2. The channels used are always identical, but the order changes (i.e. the hop pattern). So once the receiver receives its first packet, the data from said packet determines the channel hop pattern for subsequent hops. This will stay the same until the transmitter is power-cycled. The receiver will then see the change data that determines this from the transmitter, and will amend its hop pattern.

When powered-up, how does a receiver know what channel the transmitter is transmitting on? The answer it doesn't. To get the two in sync is literally as simple as listening onto any known channel that it hops on (with the channel list from either above method), and waits till it gets a data packet in. Once it has this data packet in, it knows what channel next the transmitter will hop to.

So when a transmitter hops to the next channel, on 300328-v1.8.1 it will now have to LBT (listen before talk) and see if anything else is transmitting. If it is, it doesn't transmit, and then waits till the next time slot that it can hop to the next channel. Likewise, the receiver will be listening on that channel, no data is received and so it will then timeout and hop channel on the next time slot.

This is directly in contrast to other protocols such as Bluetooth, where its frequency hopping as above, but if a channel is frequently congested, it will mark that down as not to use. This amendment to the channel hopping sequence will be then shared between both devices. This relies on the fact that both devices can talk to each other and tell each other this. For our use in RC, this is not ideal, as a two-way link can't be always guaranteed in the conditions - its more critical to have the transmitter sending the servo positions, than the receiver talking back.

Si.

This leads me to think our current TXs and RXs will not have to be updated following the change in 2015, with only new TXs getting revised firmware from the manufacturers. I would be interested to hear if others agree...

Valid for receivers only, the Tx must be updated to not transmit on the busy channel.
The receiver will work as before, without upgrades, waiting on new channel, without knowing it is busy, will get nothing because Tx is muted, then will hop on next channel, and so on.
But Tx must listen the next channel before hop, which is not done in current systems, and cut transmission if channel is busy, again not done. These must be addressed by a new firmware.

I'm slightly puzzled by this, does it mean that if you have a system that transmits continuously on a channel it has to listen before using that channel and then once it's got it it can keep it and everything else has to keep off it. If thats not the case and everything has to hop, then the transmitter will check the channel before broadcasting, but by the time it broadcasts the other system may have already changed to another channel.

Originally Posted by renatoa

Valid for receivers only, the Tx must be updated to not transmit on the busy channel.
The receiver will work as before, without upgrades, waiting on new channel, without knowing it is busy, will get nothing because Tx is muted, then will hop on next channel, and so on.
But Tx must listen the next channel before hop, which is not done in current systems, and cut transmission if channel is busy, again not done. These must be addressed by a new firmware.

OK, good stuff - I'm getting this now. Sounds like there will be no need to update existing kit at all if we don't want to, and compatability with newly bought RXs will remain for pre-2015 TXs because it's only the TX firmware that needs updating in order to meet the LBT requirement. This is looking much better than I initially thought!

Originally Posted by FrankS

I'm slightly puzzled by this, does it mean that if you have a system that transmits continuously on a channel it has to listen before using that channel and then once it's got it it can keep it and everything else has to keep off it.

Yes - that's essentially how DSM2 works. In addition it also employs Direct Sequence Spread Spectrum (DSSS) to add additional resiliency, though in practice many people still seem to report issues. However, this thread is about changes that will affect full hopping protocols only like DSMX, ACCST, FASST, AFHSS etc.

DSMX also uses Direct Sequence. It's running on top of DSM2.

Andy

Matt,

Futaba FASST/FASSTest , JR DMSS and Spektrum DSMx are DSSS systems with channel shifting capabilities.

Doug

Originally Posted by MattyB

Yes - that's essentially how DSM2 works. In addition it also employs Direct Sequence Spread Spectrum (DSSS) to add additional resiliency, though in practice many people still seem to report issues. However, this thread is about changes that will affect full hopping protocols only like DSMX, ACCST, FASST, AFHSS etc.

But thats whats puzzling me, if everything is hopping how does a system know that another system isn't about to hop on the channel it's going to hop on, plus if it looks and sees a channel occupied, but it's by another hopping system then the other system will only be on it for a few microseconds and then it will be clear again.