FrSky V8 transmitter module using Arduino and CC2500

Any old or new electronic projects on the go
Martin
Posts: 744
Joined: 16 Feb 2018, 14:11
Location: Warwickshire

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by Martin »

ozrs wrote: 07 Nov 2020, 03:48 I had wondered whether the FrSky protocols from the MPM could be flashed to the internal XJT module of the Taranis, since this should allow D8 plus D16v and D16v2 to be used.

I was told the XJT was protected to prevent this. Does anyone know what the protection is?
It uses a FrSky custom bootloader that receives encrypted files. As far as I know, no one has hacked the encryption yet. The chip is a standard STM32, so it's theoretically possible to use a programming device (STM equivalent of a USBasp) to bypass the bootloader, and upload a modified version of, say, multiprotocol. But the programming pins aren't easily accessible - you would likely have to solder wires direct to the tiny chip :? As far as I know, no one has done this yet either. This thread has some details: https://openrcforums.com/forum/viewtopic.php?t=11685
User avatar
ozrs
Posts: 114
Joined: 16 Feb 2018, 15:21
Location: West Australia

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by ozrs »

Thanks for the info Martin, makes more sense to me now.
Richard
Martin
Posts: 744
Joined: 16 Feb 2018, 14:11
Location: Warwickshire

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by Martin »

I took a look inside this old, Futaba-sized, Corona module.
coronaModule.jpg
innardsFront.jpg
innardsBack.jpg
The Corona protocol uses the same CC2500 module that the FrSky protocols use, and look at that chip (click photos for larger views) - an AtMega48V - this is pretty similar to the AtMega328 that our 8-bit Arduinos use, except that it only has 4K of Flash memory. What's more, it appears to have tracks running to PCB holes where we could attach a USBasp programmer.

My V8 ccpm sketch only uses 3274 bytes of flash - so it will fit, and it should be pretty easy to "upgrade" the module to run FrSky V8 protocol using my library - or to the FrSky D8 and D16 protocols, once I release the libraries for those.

The question is, should I bother - or is it better to leave the module working in its classic Corona form?

Edit: I searched one of my boxes of radio gear and found another Corona module - this time in JR module bay format. As expected, it has the same AtMega48V chip and programming port inside. I think at least one of these is ripe for experimentation! I see Corona modules still for sale cheap on BangGood, AliExpress, and Ebay. if they can be easily flashed to use FrSky D, or V, or even X protocol, then they're a cheap alternative to the increasingly difficult to find, or very expensive FrSky modules. :)
JRcoronaModule.jpg
Edit: I've belled out the connector pads - they are indeed an ICSP connector for attaching a (3.3 V) USBasp or similar programmer. It's 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

The other set of three connector pads, also on 0.1 inch spacing are GND, TX, and RX. I wonder if it has an Arduino bootloader that works for serial upload on those pins? :lol: Even if it doesn't, those pins will be handy for debugging, setting the fine-tuning value, or transmitter ID.

The two-colour LED is driven by pins PC0 and PC1 (that's A0 and A1 in Arduino language). The bind button links PC2 (A2) to GND when pressed. The PPM pin goes to PB0 (Arduino pin '8'); on the Futaba module it just goes via some passive components (resistors and capacitor) but on the JR module there is also a transistor in the line.

The chip select line for the CC2500, CSn is PB2 (10). The other SPI pins of the CC2500 are connected to the AtMega's SPI hardware pins (and therefore also to the ICSP connector).

PB1 (9), I think, switches the power amplifier of the RF sub-board - when it's transmitting Corona protocol, that line switches high while it sends 3 packets, then low for a while before the next three packets... but in bind mode it stays low always. PD7 (7) also seems to control transmit power - it's always high in normal Corona transmitting mode, and always low when binding.

PD2 (2) switches high about 1.5ms after each SPI operation. It stays high for about 1.5ms and then goes low again. I don't know what that does - maybe some kind of 'idle' signal from the RF sub-board?

PD3, PD5, and PD6 (3, 5, 6) also connect to the sub-board, but I've not seen them change either in normal mode or when binding: 3 seems to always be HIGH; 5, and 6 seem to always be LOW.
Last edited by Martin on 08 Nov 2020, 12:56, edited 7 times in total.
AndyS
Posts: 42
Joined: 12 Oct 2018, 19:03
Location: Biggleswade

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by AndyS »

AndyS wrote: 06 Nov 2020, 17:34 There are so many things that could cause a test setup to not work, bad connection, low battery, error in sketch config, u/s module when it is a test on a bench.
Update - I have a Basic Four Function working with servos moving.

Getting there :D

EDIT - Despite working all afternoon on it I have failed to get the Cppm version working. So this code does not work for me.
Martin
Posts: 744
Joined: 16 Feb 2018, 14:11
Location: Warwickshire

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by Martin »

If the basicFourFunction sketch is working, that proves most aspects of the library are working okay - and then it sounds like the Arduino isn't seeing any pulses arriving at its cppm pin - or at least not seeing pulses with what it considers to be valid timing.

Did you try the little sketch I posted up thread? The one that copies the cppm pin to the LED pin (with a delay when it changes)? That will show that the Arduino is actually seeing some pulses on the cppm input.

Hopefully it's not seeing any pulses at all - that will be an easier thing to diagnose and fix than badly timed pulses.
AndyS
Posts: 42
Joined: 12 Oct 2018, 19:03
Location: Biggleswade

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by AndyS »

I will try that code tomorrow. But I am using a scope to monitor the ppm pin, but does not (as you say) mean that the arduino code sees it.

It must be something about the ppm as the basic four channel worked ok.

I have used a Taranis ppm and also a Phil G encoder ppm with rates set to max and min.

Another thing I can try is find another ppm source.

Anyone else trying this yet?
User avatar
Wayne_H
Posts: 809
Joined: 17 Feb 2018, 05:26
Location: Temora, NSW. Australia
Contact:

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by Wayne_H »

Phil_G wrote: 07 Nov 2020, 21:04 No 2500s yet........
Ditto...
Cheers,

Wayne
Once a Retrobate, always a Retrobate............ ;)
AndyS
Posts: 42
Joined: 12 Oct 2018, 19:03
Location: Biggleswade

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by AndyS »

The soldering onto the small low power CC2500 can be a pain, especially if like me you are in your 70's.

This CC2500 is from a UK source so delivery is within a few days. Is soldered to a breakout board for easy connection. Is the best way to prove your set up without having to use the high power module.

https://www.ebay.co.uk/itm/CC2500-2-4GH ... 2749.l2649
AndyS
Posts: 42
Joined: 12 Oct 2018, 19:03
Location: Biggleswade

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by AndyS »

Martin wrote: 06 Nov 2020, 12:15 If you don't have a serial monitor available, I recommend this tiny sketch that will show if your Arduino is receiving a changing signal on pin 2. It looks for a change and flashes the built in LED when changes are occurring. You need the delay, because if you just copy pin2 to pin13, a genuine cppm signal changes so fast that it looks like the LED is permanently on. You'd see it with an oscilloscope, of course, if you have one.

Code: Select all

void setup() {
  pinMode(2, INPUT_PULLUP); // cppm in
  pinMode(13, OUTPUT); // built-in LED
}

void loop() {
  static int previousState;
  int state = digitalRead(2);
  if (state != previousState) {
    digitalWrite(13, state);
    delay(100);
    previousState = state;
  }
}
If you are getting a flashing LED with that test sketch, but my cppm sketch still doesn't see it, maybe it's down to the timing of your cppm signal? My sketch looks for a marker pulse interval > 3000 microseconds to indicate end of frame (in the sketch at line 164). You could try altering that down to about 2100 - but not much lower because the valid range for in-frame pulses is nominally about 988 to 2012 microseconds.
Martin - I have tried your short sketch to test the PPM and I get a nice flashing LED from a Phil G encoder PPM.

I have also tried inserting a Schottky Diode in the PPM line, but made no difference on my cppm setup.

The duration of the pulse frame from my Phil G encoder is just over 1600 microsecs.
Martin
Posts: 744
Joined: 16 Feb 2018, 14:11
Location: Warwickshire

Re: FrSky V8 transmitter module using Arduino and CC2500

Post by Martin »

For soldering, I recommend buying one of those cheap clone 'Opti-Visor' things.

https://www.ebay.co.uk/itm/Headband-Mag ... 867260754?

They cost about eight quid. The 'torch' thing is probably a waste of time - I never tried mine yet - but the ones without a torch cost more than the ones with. :roll:

It magnifies quite a bit in the 'normal' position - that's what I use for soldering. There is an internal flip-down second set of lenses that increases the magnification for both eyes - but then you have to get too close to the work for soldering, in my opinion. Likewise, the external one-eye magnifier, which you can just swivel out of the way or remove entirely.

Are you using the same pin (2) for the little test sketch that you're using for the cppm one? I know you said you swapped to using pin 3 for some reason. Make sure that the pinMode() and attachInterrupt() both refer to the same pin.

To test that the cppm signal is calling the cppmFallingEdge() interrupt handler, try this in the cppm example:

in setup() add a pinMode(13, OUTPUT);
in cppmFallingEdge() add this line before the if (interval > 3000) { one
digitalWrite(13, channel < 2);

That will switch the LED on the first time the interrupt handler is called. It will stay on until the pulse for the third channel arrives, then go off for the remainder of the cppm frame. The LED may flicker too fast to see what it's doing visually, but you can put your scope on pin 13 and you should see pulses at the CPPM frame rate - maybe 20 or 25 Hz.
Post Reply