1. In the schematics you show the leds with their cathode connected to the Atmega pins then a resistor and to ground, all schematics of a led connection I found on the net are the other way around (pic1).

My bad, I reversed the polarity of the LEDs on the schematics. Sorry. They should be the other way around, of course.

Quote:

Originally Posted by blackmoon

2. In your schematics (pic2) you don't use the atmega's SS pin, instead you connect the nRF24L01p CSN to PC1 of the atmega.

But in the file hw_setup.h, you define the following:

I know it's for the atmega644, so why use the PC1 pin in your schematic with the 168, since that MCU also has a SS pin (PB2) that one could define in hw_setup.h

Yes, that is a little confusing, but it should still work. SS on ATmega must to be defined as output for SPI to work properly as master. If you configure it as input and signal on the pin goes low, SPI will switch to slave mode even though it is configured as master. It's one of the strange quirks of the AVRs. That's why SS is defined in hw_setup but isn't connected to anything. I suppose I should have 'joined' SS and CSN into one pin for a cleaner design, but it should work like this as well. I will probably join them for the final design.

Yes, that is a little confusing, but it should still work. SS on ATmega must to be defined as output for SPI to work properly as master. If you configure it as input and signal on the pin goes low, SPI will switch to slave mode even though it is configured as master. It's one of the strange quirks of the AVRs. That's why SS is defined in hw_setup but isn't connected to anything. I suppose I should have 'joined' SS and CSN into one pin for a cleaner design, but it should work like this as well. I will probably join them for the final design.

Ok now, I understand why, thx

I have mixed something up surely, because I'm using an arduino and I maybe did some confusion on output pins, when I did the solder job.

So I'll get a breadboard it will be easier when I make a mistake to undo it, and to test the nrF board with the 'Poor Man's scanner".

One more thing, should I keep it pressed trough the bind process or just once at power on ?

No, just until the you see the bind LED turn on. After that, it should stay in 'bind mode' until it gets a 'bound' response from an RX, or until it is powered off.

I've uploaded a new version of the source code. Changes:

- It implements the copy TX ID feature that we talked about. Because of this their respective button/LED hw_setup definitions were renamed into COPY_TX_ID_BTN and COPY_TX_ID_LED.
- It searches for free channels when powered on like the stock TX does. I've described this in one of the previous posts.
- I've renamed the BIND_BUTTON_PORT and BIND_BUTTON_BIT macros into BIND_BTN_PORT and BIND_BUTTON_BIT. Reason: consistency with COPY_TX_ID.
- I've dropped the macro definitions for the third button.

The definitions in hw_setup.h in this version are still pointing to pins on my ATmega644, so if you have your own hw_setup, make sure you don't overwrite it. And remember to rename the BIND_BUTTON_* and add the COPY_TX_ID macros.

I've got a TX module case from a kind hearted soul yesterday. It's a stock 9x module case, so I will design the size of the circuit around this. But the design should work with any JR case. Just to verify this, can someone post images of the insides of other JR type cases just so I can see if it is any different? The more the merrier! Thanks.

Some case's pictures: Jr/Spektrum, McGregor/JR and some Chinese clone module that I just salvaged the case from.

Thanks for the pics and the sizes!

It looks like the "one size fits all" goal I was hoping for is not really realistic. There's no (easy) way to have support for the PCB on that JR/Spektrum module. The 9x module I have looks very similar to the Chinese clone module on the pictures and both that one and the McGreggor have support for the PCB on which the buttons will rest.

I think I'll make a two PCB design like in the 9x module. One will have the 5 pin header, buttons, LEDs, the 5V regulator and the buzzer, the other board will have the ATmega, nRF module, 3.3V regulator, quartz and a 6 pin ISP. The two PCBs will be connected with a header. If there's still more room, I might break out the nRF pins so that I can easily attach the logic analyzer for testing. Or maybe even a USB connection for a bootloader?

I have finished the first prototype of neTX. I will upload the source and the schematics in a few days, although the PCB layout is not good enough for a useable device. But I think it works very well, all things considered. It took some time for my muscle memory to readjust, but it is fun flying the SoloPro with a 9x

For the next version I will make a single panel design. It should be simpler and easier to work with.

I was wondering. How come we can't just use the Nine Eagles transceiver and put it in the Turnigy 9x the way we can the DSM2 modules from the Blade line of RTF transmitter?

Originally, it seems like they went your route and built a module around the transceiver they harvested from a RTF transmitter. thread link

Then the Th9x programmer/er9x programmers just made it so the firmware outputs the DSM2 protocol directly so the transceiver understands it. Can't we do something similar here so we don't have to build the intermediate module?

I was wondering. How come we can't just use the Nine Eagles transceiver and put it in the Turnigy 9x the way we can the DSM2 modules from the Blade line of RTF transmitter?

Well, I suppose it is possible and maybe even simpler for the end user, but I don't really have interest in doing that. My motivation in doing this is learning about electronics and the process of designing and building circuits, not flying the SoloPro with a 9x. I am perfectly happy flying my SoloPro with the stock TX. Doing it by directly soldering it into the 9x case and patching the er9x code would require digging through other's people source code and that is something I do for work, and is not what I consider fun.

Also, that would be a solution only to the people who have a 9x. What I want to do will be good for anyone who has a JR module based TX.

Is there any open source firmware for the JR ? not that I know about...

Even if it existed, am I ready to go dig an solder inside my JR ? no...

I have a RTF UM P51 Tx that I plan to gutter so I can make a module from, and even with the th9x, I'll go with the module approach from the "Build your own DSM2 transmitter module (its working!)" thread.

I really like the simpler plug unplug a module way, not talking about the fact that I can share the module between my Tx's

Hooked it up to the breadboard with the arduino programmed with the revision just before the latest one.

The neTX would switch from BIND led lit to PPM ok but the SoloPro wouldn't respond to commands (led flashing).

Changed channel order, because I had forgot that TH9x is Futaba channel order, but nothing same behavior...

I thought it was the new nRF module, so I programed the arduino with the "Poor Man's 2.4 GHz Scanner" to test the nRF module, and it was working as expected.

Programed again with the last revision of neTX this time, added button, and led for TX_COPY.

Tried to bind, finally the led on the SoloPro became solid but once again no response from the helicopter...and bind led on the neTX still lit, no PPM led...

Cycled the power of the TH9x and voila...

Now at least on the bench the SP responds well to all the stick movements from the TX.

Since I destroyed my rtf TX in the process, I was begining to worry that I would have to buy another one.

For those who will make this journey, don't harvest your module from your rtf TX, to much trouble and you risk destroying it with to much heat like I did, if your not so skilled with a the solder iron.

Now at least on the bench the SP responds well to all the stick movements from the TX.

Congratulations and thanks for the support! It's a great feeling to have someone on the other side of the globe build the circuit and make it work I've never done this sort of collaboration before and I like it

Quote:

Originally Posted by blackmoon

Now pcb etching to complete this and fly .

I can send you EagleCAD files of the previous version of the PCB(s), if you want. I don't want to upload that version because of the misplaced nRF module -- you can't close the case. I am currently working on a single PCB version. I think I will have a DIY press&peel prototype by mid next week. If that turns out well, I will order a batch of factory made PCBs from ITead.

I've fixed a bug in the encoding of the packets which caused unreliable behavior from the heli. The problem you mentioned with having to restart the TX could be due to that. I've uploaded the new version of the source code. Other changes:

- changed the hw_setup pin assignments from the old ATmega644p version to the first prototype with ATmega88pa.
- the 3.3V regulator I chose (LP2980) has an on/off feature controlled through a digital pin. This is great for resetting the nRF (not so important for the end product but very important during testing) which is a feature I wish nRF had built in. So, I've added NRF_PWR_PORT & NRF_PWR_PIN definitions and a nRF_Reset() function.

If you want to fix the bug I mentioned, but don't want to use the new source version, just change the TX_Send() function with this one:

I learned a lot doing this and it was fun (not destroying my harvested module tough), thank you again Kile.

It's a pleasure, and I learned a lot too, and I'm only just beginning

BTW, the new PCB will have a few additions:

- a FTDI cable breakout for an Arduino compatible bootloader and serial output. It will be good for configuring the channer order. Many people already have the cable, so I think this will be useful.
- Saleae Logic analyzer breakout. I love my Logic 16, so this is a must for me It takes up a lot of space, but it's worth it.
- Buzzer. Currenly it's a fixed frequency on/off version, but I will put a PWM driven one for a little frequency range.
- V-USB connection. This will allow the device to be upgraded and configured through USB if you don't have or don't want the FTDI cable. It's in the schematics at the moment, but I think I might drop this if I don't have enough space on the board. We'll see...