FrSky V8 transmitter module using Arduino and CC2500

[Martin]

You still got any Corona receivers? The CR8D, at least, has an AtMega inside with an ISCP programming port.

Sorry about the flash reflection. The other Corona receivers of the same vintage probably also have the same chip and programming port - but that's the only Corona receiver I still own (or at least the only one I can find )

Interesting that the receiver has an AtMega88V chip - so twice the RAM that the transmitter has. I don't think it needs more - it may just be that 88 chips were cheaper or more available than 48s at the time my receiver was built.

DSC00192.jpg (28.03 KiB) Viewed 46824 times

These Corona modules and receivers are pretty much perfect for experimenting with FrSky protocols, also Futaba SFHSS, plus our own home-grown protocols if anyone wants to invent one! If we designed PCBs for CC2500-based transmitter modules and receivers, I can't think of any improvements, short of upgrading the AtMega48 / 88 to a 328.

... and I think the 328 chip has the same pinout as the 48 - so if I had a few more modules / receivers to play with, I could risk doing some chip transplants.

If anyone has any old Corona gear they don't use any more, they can send it to me! Right now I've only done the V8 transmitter modification so if you flash your transmitter module with that, your Corona receivers will be (at least for the time being) useless.

For the moment, I could provide a free upgrade of Corona transmitter modules to FrSky V8 for anyone interested but who doesn't have the tools and/or inclination to tackle flashing their own module. And I could accept donations in the form of old Corona receivers!

The transmitter modules I know work are the CT8F and CT8J - but if anyone has any different modules they could take a look inside, or send them to me - they may also have AtMega and CC2500 chips.

[AndyS]

My small version ready for installation and testing in a transmitter.

[Martin]

Very nice!

I forgot to say, I did some range tests at the flying field on the day before lockdown. This was just with the little CC2500 board with no power amplifier and the small on-board PCB antenna.

First I hung the receiver off a fence, and walked away with the little transmitter. It was a sunny day, so difficult to see the receiver LED from distance, even with binoculars. I was trying to see which orientation of the transmitter PCB gave the poorest range. But once I got over about 75 yards away, I couldn't see the receiver LED - and at the limit of my vision, the link was still solid - a solid receiver LED with no blinks, and at that distance the orientation of the transmitter PCB made no difference.

So I gave up on that test and stuck the transmitter up on the open tailgate of my car, in a random orientation, and walked away carrying the receiver.

I had to cross two fields, and climb over a stile before the receiver LED started to intermittently blink, indicating I was at the limit of the range. I would never normally fly that far away - and of course, the range would be greater in the air. I couldn't even see my car when I began to lose the signal, as I'd turned a bit of a corner and there were some barns in the direct line-of-sight to the transmitter.

So I walked back a different way, sticking to a farm track. I was getting nearer the car (and hence transmitter) but there were more buildings in the way - larger brick-built barns with corrugated metal roofs. Anyway the signal remained solid, even as I turned the receiver in different orientations, held it close to the ground, and so on.

I was mightily impressed. Okay, a fairly quiet 2.4 GHz radio environment - with only one other modeller flying at the time - but the range was as good as I would expect with many commercial systems with 'proper' transmitter aerials.

I've not tested the range of the bigger module with the power amplifier and bigger external antenna yet. I'm expecting it will be a very long walk before I reach the range limit, or perhaps I need to take a bicycle or my car?

[Small-RCer]

Just in time for Christmas shopping.

Seem to be on sale or are very cheap knock offs.

Will be great to convert a pair of high end Futaba 72MHz Tx to FrSky V8. Now all my Tx will be FrSky.

https://www.aliexpress.com/item/1005003611530792.html

Hopefully Martin's code will just work. If code space is too small, I will swap the CPU.

The page may be in CDN dollars but is about $21.00 US, including shipping to Canada, which is a pretty good deal.

Thank you Martin for your work.

Jim H

[Martin]

Thanks.

Those AliExpress Corona modules and receivers are indeed cheap, but the seller doesn't ship to the UK, so we can't buy them!

[Small-RCer]

Received a pair of the Corona CT8F modules from Aliexpress, today. They look okay. Now to work on the firmware change.

What was interesting was they had a manual. Also each had on the package this label. It shows the UK representatives company name and email address.

It may be of use to those in the UK looking for UK stockists or distributors.

[Small-RCer]

Hello Martin.

I have watched both of your videos of the Corona Tx module usage and programming, several times. The 2nd video shows the steps to compile. It does not show uploading to the Corona module. It does show the selections required to set the correct Atmega chip and other parameters. All this makes it quite straight forward. Thanks.

But I do have a few questions. The first is the only one key to my proceeding. The others are just curiosity.

During programming / uploading to the Atmega48 of the Corona module, is the module powered from the Tx and thus requires the Tx battery in place and being powered up? Or is the power from the USBasp all that is required to program the ATmega48?

You do use the serial output, which I appreciate is a useful tool for diagnosing performance. If the serial printer code is not included, is there enough space left to make the Tx D8 and D16 compatible?

Does your code implement the original ACCST protocol?

Do you know if the EU requirement of Listen Before Talk (LBT) is required in the Tx modules or only in the telemetry back to the Tx?

Thank you for your great work on these modules.

Regards.
Jim H

[Martin]

Hi Jim. When programming the Corona module, the USBasp power is sufficent - no need to connect the Tx battery. Use a 3.3V USBasp, and check with a multimeter that it really is 3.3V maximum on all pins before connecting. I've seen some USBasps that can be switched to 3.3V, but only the VCC pin is affected - MOSI and SCK still run at 5V: I wouldn't risk using those - the 5V might 'leak through' to the CC2500 chip and damage it.

Six pins in a line with 0.1 inch spacing. Starting from pin 1 (the square pad) the connections go: 1:MISO 2:VCC 3:SCK 4:MOSI 5:RST 6:GND

I think I did the D8 version and got it running on the Corona module - so there's space - I don't remember whether I still left the serial debug code in place. It was a separate sketch to the V8 one: without a major space-saving rewrite there's not enough room for both V8 and D8 code in the same module - and even if you could squeeze it in, you'd have to figure out a way of allowing the user to change modes by using the bind button, or similar.

I should dig out that code, test it again and upload it here. No easy way to hook up any telemetry received back by the module, so I left out the telemetry decoding part.

I never got round to doing the D16, but I think it would probably fit. What I remember of the Muliprotocol code, D16 isn't so very different to D8. But there are many flavours of D16: International or LBT, and X1 or X2: I think you'd need to choose one and stick with it - and then you'd find people wishing to use it would complain because you chose a different flavour to the one they use, and they don't want to reflash all their D16 receivers.

To make it work, you have to dig through the muliprotocol code, gradually pruning away all the protocols except the one you want until it's small enough to fit in the module's FLASH memory. It's not much fun, because the parts you need are spread across loads of different source files, intermingled with irrelevant stuff for other protocols and microprocessors: there are lots of conditional compilation parts based on complicated #define options. The multiprotocol code has evolved over time, so it's rather messy and difficult to understand.

I think ACCST was just the acronym FrSky used for its D8 and D16 protocols. I don't remember if they ever used that acronym for V8 also. So if you have a mulitprotocol module or one you've built or modified yourself, and it works with D8 receivers (and maybe V8) then I suppose it's implementing the ACCST protocol. But I don't know if the multiprotocol code ever claimed to implement ACCST, or just be 'compatible with it' - and my code is just a pruned version of the multiprotocol code.

I think to be EU-legal, LBT is required even if the transmitter module doesn't bother to listen for any received telemetry. As I understand it, the rules forbid transmitting on a particular channel with more than some specified power level for more than some specified length of time unless you first listen on that channel to make sure it's clear before beginning to transmit. So you shouldn't be switching on a new non-LBT transmitter in Europe, even when there are no receivers switched on to listen to the signal and possibly respond with telemetry packets. But, as far as I know, the rules only forbid the selling of new equipment, so the use of D16 international (and D8) transmitters that were sold before the LBT versions came out, is still legal.

[Small-RCer]

Thanks Martin.

I will stick with the code that you have posted. I contacted LC Technology who made the particular USBasp programmer that I bought. I asked them very specifically if switching to the 3.3 setting absolutely switched the level of all the lines. They understood what I was asking and were adamant that the switch was all the I/O lines and not just the voltage line.

I will test all the lines before I connect to the CT8F.

I soldered a 6 position female header on the board as I have many male to male jumpers for use on prototype boards.

As I do the work I will photograph the work and make notes.

I have numerous V8 receivers so this module will come in handy. Around here most flyers have moved off 72 MHz radio gear. Formerly high end Tx are often free for the asking. Futaba 8 channel computer radios are seldom more than $20 to $40 CDN. A $25 module and time at the computer makes a welcome upgrade.

Aloft Hobbies in the US have developed new firmware for the FrSKY receivers. The have worked with FrSKY to correct some of the shortcomings. The Aloft forum has some details of the work and the time line for the release. Aloft seem to have some pretty clever programmers on staff.

https://forum.alofthobbies.com/index.ph ... ming.2252/

Thanks for your very detailed response. I look forward to your future projects.

Regards

Jim H
Halifax, NS, Canada