Chinese radio chip A7105

[Mark Robson]

Hi all,

I've got a Chinese radio chip, the A7105 (datasheet here: http://files.banggood.com/A7105%20Datasheet%20v1.4.pdf ) which I want to use to receive from a FlySky AFHDS2A radio controller.

This should be possible, as others have done it before, for example, in the Deviation TX open source project ( https://www.deviationtx.com/ ) and some others.

I've wired the XL7015-SY module (which is a module which contains the A7105 radio chip, its passive support components, crystal and an antenna) to my microcontroller with the SPI connections (and power).

I can communicate with the chip just fine, and I can see its registers, program them, and it behaves in the expected way.

But despite my best efforts, I've managed to receive absolutely no useful packets whatsoever from the Flysky transmitter. It's never recorded a valid packet. I can see some error flags being set, and the rx buffer fills with random junk occasionally though - so presumably it's receiving, but it isn't receiving what it wants.

I'm probably doing something wrong - either that, or the module is faulty (I have some more, but I don't really want to solder it again, it was fiddly).

Does anyone have any equipment / experience, to help me out? I'm going to (try) to CC this message to the RADARC mailing list.

It is possible that I could wire up a second A7105 and try to have one transmit and the other receive, but that would need more effort.

Any ideas would be welcome!

Thanks in advance,

Mark

[Gavin]

From my experience of getting NRF24s talking to each other (also 2.4G GFSK) there are potentially a lot of settings (channels. pipes, data transmission rates, auto ack) required to get data flowing. Any one of them incorrectly set can lead to data not being received. In the case of NRF24s, some of the settings aren’t exposed by libraries and you need to poke around in registers to get them working, and it can be a bit laborious to sort out.

I’d go down the route of making up a second board to receive and program with matching settings. That way you’ll know if you’ve got working components and whether it is worth the effort of testing a potential multitude of settings

Gavin

 

---

From: reading-...@googlegroups.com on behalf of Mark Robson <mar...@gmail.com>
Sent: Sunday, September 1, 2019 8:14 pm
To: reading-...@googlegroups.com
Subject: [RDG-Hack] Chinese radio chip A7105

 

--
You received this message because you are subscribed to the Google Groups "rLab / Reading's Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reading-hacksp...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/CAJ4NLMeSCfLScvP%2BR_ByhEYCGO3PU5Hn1GFW40fnoJTw7A%2Bt3g%40mail.gmail.com.

[Mark Robson]

Thanks, Gavin. There are many settings, but the vast majority of them I'm setting them to the same value as another known firmware which (apparently) works.

While it would validate the hardware, it won't really help me much to have one chip talking to another, I really want it to receive from the transmitter, to be able to reuse the transmitter hardware. I have two of these TXs and they are quite good.

I may go down that route eventually.

Mark

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/AM0PR03MB499438CD0D153A079FBE40ABF0BF0%40AM0PR03MB4994.eurprd03.prod.outlook.com.

[Richard Ibbotson]

The AFHDS protocol looks fairly complex. Are you using an existing library or writing your own?

Sent via Richard's Phone

--

[Mark Robson]

I'm writing my own, but I will adapt the source that other people have used.

The packet format isn't complicated, it's really the channel frequency hopping scheme that might make it tricky. It's not got a public specification, but several have reverse engineered it and made compatible implementations, I'm hoping to reuse/adapt their work. I also don't need to use all the features, for example, I'm not planning to send any telemetry back.

Mark

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/63B46B5D-40C3-44B5-8777-8A554D097C42%40btinternet.com.

[Richard Ibbotson]

Do you have a link to a reverse engineered protocol specification or a working version of receiver source code?

 

I guess the first thing you need to do is to work out how to bind with the transmitter. As you say even before that you need to understand well how the frequency hopping over the 135 RF channels works. Once you know what frequency you are working on you could check the RSSi to see if you are getting the signal from the transmitter before demodulation.

 

Why do you want to control the A7105 direct when the full receivers are low cost? You might just interface to the i-bus of a receiver.

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/CAJ4NLMeyZ9F7TA07UqQxzYP6qJbUwmqWz6HjAmpX2HFWAi8sYQ%40mail.gmail.com.

[Mark Robson]

The RXs are low cost. Yes. I've interfaced with them by i-bus already; that works. I'm trying to make a more integrated / smaller package to go into very, very small robots :)

A working receiver implementation is apparently. here:

https://www.rcgroups.com/forums/showthread.php?1921870-DIY-FlySky-TX-RX-module

These are Arduino source codes for some microcontroller that I don't have. It's possible that some of those versions are for earlier versions of the protocol (Flysky) which aren't compatible, but honestly, I'm not sure about anything right now.

Also there are some docs here and some more implementations for (perhaps) a different arduino / hardware:

http://thierry.pebayle.free.fr/RX_A7105/

There are also some files somewhere in these, which contain SPI dumps from people reverse-engineering commercial RX modules.

Mark

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/003a01d56109%24f1511340%24d3f339c0%24%40btinternet.com.

[Richard Ibbotson]

This looks like a receiver implementation for the PIC http://thierry.pebayle.free.fr/RX_A7105/Banggood_micro_receiver/banggood_micro_receiver_sangyue.c

 

This appears to be valid description for AFHDS 2 https://github.com/DeviationTX/deviation/blob/master/doc/Flysky.txt

 

And this an implementation of a transmitter https://github.com/DeviationTX/deviation/blob/master/src/protocol/flysky_afhds2a_a7105.c

 

The first thing to understand is the frequency tables and hopping. What frequency and channel are you listening on to begin with?

The transmitter code appears to generate 16 random and distributed channels, though the receiver code looks like it uses pre-set channels. The transmitter sends the channels to the receiver during the bind process. The bind process seems to alternate between two pre-set channels,  “A7105_WriteData(packet, 38, packet_count%2 ? 0x0d : 0x8c);”, 0x0d and 0x8c.

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/CAJ4NLMd_V8r8kCARTzuLVsKiiboLxDEFNf3-i4bu8tfkGX5G0w%40mail.gmail.com.

[Mark Robson]

I am currently trying to get it to receive *anything* - all the rx implementations I've seen listen on channel 0 during the binding process, which doesn't use channel hopping.

So I've got it on channel 0. However, I'm receiving nothing so either I'm programming the chip incorrectly, missing something, or the radio frequencies are all messed up.  Obviously I've tried putting the transmitter into bind mode (transmitter is tested and working with a commercial receiver).

I currently don't have the GIO1 pin wired up, so I'm going to try to get that set up, because it's possible that there is a small window to read a valid packet which my code is somehow missing.

The chip starts up and receives nothing for a while, then starts receiving huge amounts of random invalid data (with the error flags set) into the receive buffer. Actually it's behaving like quite a good random number generator :)

I guess if I come to the hackspace I can possibly check that the clock is running at the right speed by enabling the clockout pin (which isn't broken out in the break-out module, so I will need to solder a fine wire to a pin, joy!)

Mark

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/004301d56118%2456b8d200%24042a7600%24%40btinternet.com.

[Richard Ibbotson]

The most understandable code for a receiver I found here. https://os.mbed.com/users/pebayle/code/A7105_FLYSKY_RX/

It uses SDO on GPIO1 and the wait signal on GPIO2. I assume you have the GPIO pins too.

 

It seems to look for a bind on channel 0 as you describe, which means the transmitter must be sending on channel 1 because the IF frequency is equal to the channel spacing. This should be on a frequency of 2400.501MHz from my interpretation of the configuration. I have a Turnigy Evolution radio which is AFHDS 2A I think. I will try to find time tomorrow to hook it up to the spectrum analyser or SDR to check the frequencies it is using.

 

After “bind” it may be best to look on the channels in the channel number table, but don’t forget to subtract 1 to get the Rx channel number from the Tx Channel number due to the IH offset

 

If you wish we can take this topic off the Google group. Or unless others are interested to keep it here.

Richard

 

 

From: reading-...@googlegroups.com <reading-...@googlegroups.com> On Behalf Of Mark Robson
Sent: Monday, September 2, 2019 9:35 AM
To: reading-...@googlegroups.com
Subject: Re: [RDG-Hack] Chinese radio chip A7105

 

I am currently trying to get it to receive *anything* - all the rx implementations I've seen listen on channel 0 during the binding process, which doesn't use channel hopping.

 

So I've got it on channel 0. However, I'm receiving nothing so either I'm programming the chip incorrectly, missing something, or the radio frequencies are all messed up.  Obviously I've tried putting the transmitter into bind mode (transmitter is tested and working with a commercial receiver).

 

I currently don't have the GIO1 pin wired up, so I'm going to try to get that set up, because it's possible that there is a small window to read a valid packet which my code is somehow missing.

 

The chip starts up and receives nothing for a while, then starts receiving huge amounts of random invalid data (with the error flags set) into the receive buffer Actually it's behaving like quite a good random number generator :)

 

I guess if I come to the hackspace I can possibly check that the clock is running at the right speed by enabling the clockout pin (which isn't broken out in the break-out module, so I will need to solder a fine wire to a pin, joy!)

 

Mark

On Sun, 1 Sep 2019 at 22:55, 'Richard Ibbotson' via rLab / Reading's Hackspace <reading-...@googlegroups.com> wrote:

This looks like a receiver implementation for the PIC http://thierry.pebayle.free.fr/RX_A7105/Banggood_micro_receiver/banggood_micro_receiver_sangyue.c

 

This appears to be valid description for AFHDS 2 https://github.com/DeviationTX/deviation/blob/master/doc/Flysky.txt

 

And this an implementation of a transmitter https://github.com/DeviationTX/deviation/blob/master/src/protocol/flysky_afhds2a_a7105.c

 

The first thing to understand is the frequency tables and hopping. What frequency and channel are you listening on to begin with?

The transmitter code appears to generate 16 random and distributed channels, though the receiver code looks like it uses pre-set channels. The transmitter sends the channels to the receiver during the bind process. The bind process seems to alternate between two pre-set channels,  “A7105_WriteData(packet, 38, packet_count%2 ? 0x0d : 0x8c);”, 0x0d and 0x8c.

 

 

 

From: reading-...@googlegroups.com <reading-...@googlegroups.com> On Behalf Of Mark Robson
Sent: Sunday, September 1, 2019 10:21 PM
To: reading-...@googlegroups.com
Subject: Re: [RDG-Hack] Chinese radio chip A7105

 

The RXs are low cost. Yes. I've interfaced with them by i-bus already; that works. I'm trying to make a more integrated / smaller package to go into very, very small robots :)

 

A working receiver implementation is apparently here:

--

You received this message because you are subscribed to the Google Groups "rLab / Reading's Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reading-hacksp...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/004301d56118%2456b8d200%24042a7600%24%40btinternet.com.

--

You received this message because you are subscribed to the Google Groups "rLab / Reading's Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reading-hacksp...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/CAJ4NLMcdSoqy49NrfYSRw7z%3DBuGPLqW8Q%2Bdi6L_gPfbJXOm78A%40mail.gmail.com.

[Vance Briggs]

Keep it on the group, or at very least summarize progress. I am interested...

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/006501d561db%240b186d60%2421494820%24%40btinternet.com.

[Mark Robson]

Thanks, Richard, this one, https://os.mbed.com/users/pebayle/code/A7105_FLYSKY_RX/ is the clearest example yet, but also seems mostly similar to the others. As far as I can tell, the register settings they all use are approximately the same, or differ in ways which I understand (different RXs use GIO1 and GIO2 line differently in hardware). This is also (I think) the only sample which seems to use GIO1 and GIO2, to do 4-wire mode SPI. 4-wire SPI does not seem necessary, however, in this case.

This is also the only one written in C++ (which I view as unnecessary on such a small embedded system, maybe its runtime uses a lot of flash memory, I don't know)

Mark

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/006501d561db%240b186d60%2421494820%24%40btinternet.com.

[Richard Ibbotson]

Hi Mark,

I agree the SDO and the C++ are not required, I just liked the clarity of the code.How do you check the Rx wait?

Having looked at my Turnigy Evolution on a HackRF SDR during the bind, I see Binding on channels 0x0D(2406.5MHz) and 0x8C(2470MHz) which is as I suggested in an earlier post. If your setup for the A7105 does not have IF offset you will need to set to receive one channel lower.

Good hunting, or we can can check with your transmitter

Richard

[Mark Robson]

I can try to knock something up which will scan all the channels.

I think it's possible to receive the rx status by polling the status register 0x0, but I'm not completely sure about that because the Chinese-translated data sheet uses very ambiguous language. It might also be possible by reading FIFO register 1 (0x03) which possibly will indicate a nonzero value after packet is received, but who knows?

Anyway I plan to connect the GIO1 line and can monitor that (via irq if necessary)

Mark

--
You received this message because you are subscribed to the Google Groups "rLab / Reading's Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reading-hacksp...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/0fe1421e-de07-482d-8d1c-2fd2347fd7eb%40googlegroups.com.

[Mark Robson]

Hi,

A quick progress update - I have modified the code to scan channels correctly, and now I can receive *something* from the transmitter.

It seems that channel 0 doesn't receive any packets from the TX. The lowest channel number which gets anything is 0xc, and that is receiving almost valid packets with some corruption. It is clearly nearly right, but not quite.

I am fairly sure that the oscillator in the chip isn't tuned at exactly the right frequency, and I can see some code in the transmitter firmware here ( https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Multiprotocol/A7105_SPI.ino#L171 ) -  A7105_AdjustLOBaseFreq - which tweaks the frequency registers in some way which is configurable at compile-time, I will have to hack the DIY-Multiprotocol source more to understand exactly what it's doing (it is actually designed for several different RC protocols which use the same chip, with slightly differing settings).

Mark

[Richard Ibbotson]

Hi Mark,

Thanks for the update.

 

Are you looking at signal during bind or in s-Bus operation?

 

When you say channel 0x0C do you mean the channel you set the Rx to ( this would be the Tx Channel -1 due to the IF offset)? If you get the bind messages, then they contain both the transmitter Id and the channels to be used subsequently in the message.

 

I did not look at the calibration part but can help measure any offsets you have.

 

Good to hear progress.

Richard

 

From: reading-...@googlegroups.com <reading-...@googlegroups.com> On Behalf Of Mark Robson
Sent: Sunday, September 8, 2019 3:55 PM
To: reading-...@googlegroups.com
Subject: Re: [RDG-Hack] Chinese radio chip A7105

 

Hi,

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/CAJ4NLMd0YQfbJz%3DTp158MT29%2BC%2BhZ78voKmHQbrumzeHfFpPQA%40mail.gmail.com.

[Mark Robson]

Ok, another update:

It looks like I've largely solved the problems. The main problem was that I was reading the documentation and examples for the old Flysky protocol, which is not compatible, or particularly similar to the AFHDS2A protocol, which my TXs actually use, despite using the same chip.

The AFHDS2A protocol also uses channel hopping, but has many differences in details. Firstly, the bind packets are not sent on channel 0x0 (or 0x1) - but rather 0xd and 0x8c. Secondly, the packet header data are rather different, although the sticks position data are similar.

Once I set all the registers to the correct values for AFHDS2A, it worked a lot better and I am getting packets which aren't garbled and actually contain the expected data.

In particular, there is a flag called "FEC" or "forward error correction", without this flag set, the radio returns totally junk and errors!

Also, the packet length byte, has to be exactly correct otherwise the packets are all errors (I guess this is because of some kind of error checking which always fails). I don't think the length is in the packets themselves, so the rx and tx always need to agree precisely.

It looks like the afhds2a protocol is better from the rx implementation too, because the hopping channels are actually sent during the bind process and can be stored in nvram, rather than relying on a weird lookup table based on the transmitter id.

Mark

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/000a01d56658%24d95f8a10%248c1e9e30%24%40btinternet.com.

[Richard Ibbotson]

That is great news. You have clearly put a lot of work into this and it has paid off.

Is this the project you will present at Geek Night tomorrow?

Richard

[Mark Robson]

Hi,

Just a quick update...

I was quite pleased once I got the chip to receive packets, I think the battle was almost won.

A lot of other issues came up since then, but I've solved them all successively,

* As Richard correctly said, the receiver needs to be tuned to 1 channel less than the transmitter, otherwise it receives very few packets

* My microcontroller wasn't fast enough to process the packets at its default (3ish mhz) clock rate, so I needed to increase it (now 10mhz), and also improve the code efficiently. Packets arrive every 3.8ms, although I probably don't need to process every single one; if I'm still short of time, I can just have it skip half the packets.

* My timing routines were dodgy and caused the timing to run backwards occasionally which caused all sorts of trouble

Now I've got it reading the bind packets, binding to the transmitter and storing the parameters in flash; it will receive the sticks data in normal mode, hopping to the different channels as the transmitter does. It also has the logic to skip missed packets and correctly resynchronise. I've tested it at a moderate range of about 30 metres and it still receives the majority of packets, with a few dropouts. Not bad for a 16x21mm module with a tiny pcb antenna.

The rest of the firmware coding is mostly a formality as it's stuff that I've already done in the previous version of the ESC (driving motors etc).

Code is here, it is a bit messy:

https://github.com/MarkR42/malenki-esc/tree/master/firmware/nano

Mark

--
You received this message because you are subscribed to the Google Groups "rLab / Reading's Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reading-hacksp...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/reading-hackspace/45483006-A24B-421C-961D-D45AD6A7C85C%40btinternet.com.