- Posts: 1386
V202 protocol
- victzh
-
Topic Author
- Offline
I would like to port it to Deviation, but the problem is, as far as I understand, limited chip select pins in easy availability. I'm not afraid of soldering - I design PCBs myself and can deal with 0201, so to solder to a spare pin is not my personal problem. But it can be for people who'd want to use the solution themselves. As far as I understand there are already two additional modules - A7105 and CC2500. I don't have any CC2500 models (yet), so what do you think of reusing CC2500 pin?
Please Log in or Create an account to join the conversation.
- rbe2012
-
- Offline
- So much to do, so little time...
- Posts: 1433
And you can use your own pin when you are able to solder directly to the MCU.
Please Log in or Create an account to join the conversation.
- victzh
-
Topic Author
- Offline
- Posts: 1386
Don't judge too hard - I know it's sloppy, but the goal was to make it work, not to have a piece of engineering.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
- Posts: 4402
Your begin statement can be translated to an init() function
command() becomes a build_data_packet() (and the tx part goes into the _cb() function. The nrf stuff goes into target/devo_common/protocol/nrf24l01.c
It looks like an easy project to convert it to a deviation module.
As you mentioned, we'd need to figure out the frequency hopping table to do this right. In the past what i did was to hook up my Salaea to the Rx, then use my test-setup (and rpi) to transmit a txid, wait an amount of time, toggle a gpio to reset the rx, and do the next one. Then I'd just run it for hours with the Salaea capturing its longest run (~ 20 minutes). This allows me to watch the Rx scan the channels for a given txid. and to push a huge number of ids through. the same thing would work just as well (probably better) with your arduino setup.
If you are setup to collect the data, that'd be great. Otherwise, once this is working in Deviation I can run the above scripts.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
- Posts: 4402
If the protocol requires Tx only, you can just tie CE high and then toggle between 'Standby-II' and 'TX Mode'. If you need Rx, you need to pass through 'Power Down' which incurs a 1.5msec cost.
I haven't looked at the BK2421 but if we could use it to talk to the full range of nrf24l01 protocols instead, and it uses a proper 4-pin protocol it may be interesting to put the BK241 module in the tx instead.
Alternatively, we could wire the 4-pin SPI ito 3-pin using a resitsor between the 2 pins and then operate it like an A7105. That would let you use the miso pin as a CE pin though I dunno what happens if you toggle CE a lot when the module is not in use.
One more option is to share the reset pin used by the cyrf6936 module. I'm notsure how the cyrf module takes to being held in reset, but if it doesn't affect power, that mightbe another option.
Edit: I just looked at the BK2423 data sheet. It's state machine looks awfully similar to the nrf24l01, and it also seems to require CE. I can't tell whether you can bypass this requirement as in the nrf chip without spending more time looking at it though.
Please Log in or Create an account to join the conversation.
- victzh
-
Topic Author
- Offline
- Posts: 1386
I see the problem. I yesterday soldered SPI to receiver once again - my first try broken off. It took me 2 hours to solder 2 wires back to wires between processor and RF chip. I understand why you're hesitant to force people to solder to the chip directly - I can do it, you can do it, but it requires skills and enormous efforts with non-zero probability to ruin your new toy.
So, what do you think about small multiplexor - board with a switching chip(s) which routes 6 wires to 4 different chips and is guided by another 2 wires? We do have relatively easily accessible 8 pins, don't we? And you probably don't need even to multiplex 6 of them - 2 is enough. For CYRF they'll go to CSN and RESET and for nRF - to CSN and CE. For this schema the only needed trick is to unwire CSN and RESET from stock connector.
So, as I understand we need to solve the connection problem first.
I know you felt it sometime in the past, but it's amazing feeling that something flies guided by your code. I put my breadboard and batter on my gutted Devo 7 (the one I wrote you about sometime ago - with faulty power supply) and actually flew my V202!
WRT further frequency hopping reverse engineering: It appears that after receiving an id the receiver tunes to the channel it expects its next packet and then if it's not actually comes it does not switch to the next channel but stucks waiting for it. So I thought about writing a program which instead of Saleae sniffs the receiver radio itself and sends the next expected packet thus speeding up sequence recovery procedure.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
- Posts: 4402
www.deviationtx.com/forum/7-development/...module?start=20#8384
I actually use an 8-way multiplexor for CSn on my RPI test setup, and it works well. asking someone to breadboard one of these is quickly getting past most people's capabilities though, so to me it looks like something that needs to be pre-made. If we're going that way, might as well go whole-hog and actually put all the chips on one board along with an STM32 processor and then make a module that can plug into any transmitter. On a Devo you'd only use the STM32 as a mux, but they're cheap and you could then have one board design that meets the entire set of needs.
My big problem is that (a) I have very little experience mounting QFN parts, (b) I have no experience at all with designing RF circuitry (c) even if I designed the whole thing and got it working, I'm not sure about the liability of actually selling it.
For the moment I'm more likely to try one of the other solutions I proposed to get around the issue for the time being.
Please Log in or Create an account to join the conversation.
- victzh
-
Topic Author
- Offline
- Posts: 1386
So switch board for several daughter boards is wasting resources, but more realistic if you don't have access to network analyzer.
I did one RF design by closely copying reference design and it seems to be working, but I did not check signal strength yet. And it's 900MHz design.
QFN is no fun also - I did it, but it's rarely goes well the first time you put it on the board and fry it. You must have stencils for QFN, otherwise it's torture.
If I can help designing an actual switch board, just tell me - I'll gladly design any non-RF (or RF, if you're not interested in quality

Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
- Posts: 4402
I think I'd like to use a uC instead of a switch. You could talk to it via SPI and need only 2 io:
take the cyrf reset pin as the CS for the uC, and then pass the 2nd pin as a CS to whichever module is specified. This also lets you support 5-pin modules by sending specific commands to the uC to turn on/off the relevant pins.
You could probably get by with a PIC or AVR without issue (though again, using an STM32 allows using the Deviation protocol code to build a PPM universal module (with a bunch of antennas)
The goal here would be to build something that could be easily assembled by someone without much experience. You could do that with all through-hole components I suppose (I'm not knowledgeable on AVR, but PIC has several parts with high-speed on-board resonators if accuracy isn't important..I really liked the 18f14k50 as a low-pin count USB-capable chip). In that case we'd just be building a Devo-only module. If we could actually manufacture and assemble the boards, using smaller SMT chips could make the board more capable as described above.
We can take this discussion over to the Universal Module thread. I'm certainly open to suggestions on how to proceed.
Please Log in or Create an account to join the conversation.
- victzh
-
Topic Author
- Offline
- Posts: 1386
Please Log in or Create an account to join the conversation.
- vlad_vy
-
- Offline
- Posts: 3333
Please Log in or Create an account to join the conversation.
- victzh
-
Topic Author
- Offline
- Posts: 1386
Please Log in or Create an account to join the conversation.
- Usjak
-
- Offline
- Posts: 24
Please Log in or Create an account to join the conversation.
- Daryoon
-
- Offline
- Posts: 260
But come to think of it, I don't think anybody tried testing for compatibility.
Once my friend's v202 comes in, I'll test to see if it binds to the HiSky radio and we'll know for sure.
Please Log in or Create an account to join the conversation.
- victzh
-
Topic Author
- Offline
- Posts: 1386
Please Log in or Create an account to join the conversation.
- victzh
-
Topic Author
- Offline
- Posts: 1386
I updated the code in my V202 repository with frequency hopping algorithm and modularized it a bit. I also successfully built Deviation, so the next step is I try to solder the module (I use ribbon cable with header at the end, so the modules are detacheable) to my Devo 10, and port the code to Deviation. For V202 there is no need to switch from TX to RX, so I just wire CE to Vcc - I tested it to work on my Arduino model.
Please Log in or Create an account to join the conversation.
- victzh
-
Topic Author
- Offline
- Posts: 1386
Please Log in or Create an account to join the conversation.
- PhracturedBlue
-
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- Daryoon
-
- Offline
- Posts: 260

Please Log in or Create an account to join the conversation.
-
Home
-
Forum
-
Development
-
Protocol Development
- V202 protocol