HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Jan 06, 2012, 02:19 AM
Registered User
hungary
Joined Jan 2011
113 Posts
Quote:
Originally Posted by blackmoon View Post
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 View Post
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.
kile is offline Find More Posts by kile
Reply With Quote
Sign up now
to remove ads between posts
Old Jan 06, 2012, 05:23 AM
flying beam
blackmoon's Avatar
through the Looking Glass
Joined Apr 2008
1,756 Posts
Quote:
Originally Posted by kile View Post
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".
blackmoon is online now Find More Posts by blackmoon
Reply With Quote
Old Jan 08, 2012, 07:03 PM
flying beam
blackmoon's Avatar
through the Looking Glass
Joined Apr 2008
1,756 Posts
Bought a breadboard and built the circuit.

PPM detection works led is lit.

However I have an issue with bind.

I'll try to explain how it works, maybe I missed a step :

Defined in hw_setup.h the bind button to PB1 (I tried PD4 , 5 , 6 because I did think that I maybe burned the port D so I went with B1 with same result).

Then compiled and loaded, if I don't push the Bind button, the pin B1 is in a high state (4.7v) when it's pushed it fall to 0.13v low state.

In the main.c

Code:
X_Init();
	
	// do the binding if the button is pressed
	if ((PIN(BIND_BUTTON_PORT) & _BV(BIND_BUTTON_BIT)) == 0)
		TX_Bind();
...
I think this is :

If the pin is in low state start bind routine.

At the beginning of bind function in netx.c, we found :

Code:
void TX_Bind(void)
{
	// turn on the bind LED
	SetBit(PORT(BIND_LED_PORT), BIND_LED_BIT);
...
if I understand correctly the first thing this function does is light up the LED, even if the nRF24L01 isn't present or just not responding.

Then do all the mambo jambo and at the end if bind succeeded shut off the LED.

Even tough, the PB1 pin go from a high state to a low one when I press the button, the bind led never light up.

I'm in the dark here...
blackmoon is online now Find More Posts by blackmoon
Reply With Quote
Old Jan 09, 2012, 12:29 AM
Registered User
hungary
Joined Jan 2011
113 Posts
Quote:
Originally Posted by blackmoon View Post
Even tough, the PB1 pin go from a high state to a low one when I press the button, the bind led never light up.

I'm in the dark here...
The state of the bind button is only sampled when the circuit is powered on. So, you have to hold the bind button down while you turn on the device. Pressing it later has no effect.
kile is offline Find More Posts by kile
Reply With Quote
Old Jan 09, 2012, 04:49 AM
flying beam
blackmoon's Avatar
through the Looking Glass
Joined Apr 2008
1,756 Posts
Quote:
Originally Posted by kile View Post
The state of the bind button is only sampled when the circuit is powered on. So, you have to hold the bind button down while you turn on the device. Pressing it later has no effect.
Ok, now I feel stupid...!

Of course is works like any other brand of TX/module (press while powering on)

Note to self : "go to bed early..."

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

Thank you.
blackmoon is online now Find More Posts by blackmoon
Reply With Quote
Old Jan 09, 2012, 06:00 AM
Registered User
hungary
Joined Jan 2011
113 Posts
Quote:
Originally Posted by blackmoon View Post
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.
kile is offline Find More Posts by kile
Reply With Quote
Old Jan 09, 2012, 08:18 AM
flying beam
blackmoon's Avatar
through the Looking Glass
Joined Apr 2008
1,756 Posts
Some case's pictures: Jr/Spektrum, McGregor/JR and some Chinese clone module that I just salvaged the case from.
blackmoon is online now Find More Posts by blackmoon
Last edited by blackmoon; Jan 09, 2012 at 09:57 AM.
Reply With Quote
Old Jan 09, 2012, 11:22 AM
Registered User
hungary
Joined Jan 2011
113 Posts
Quote:
Originally Posted by blackmoon View Post
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?
kile is offline Find More Posts by kile
Reply With Quote
Old Jan 09, 2012, 04:02 PM
flying beam
blackmoon's Avatar
through the Looking Glass
Joined Apr 2008
1,756 Posts
Bad news, my 3.3v regulator died on me, and I think it took the nRF module with him, it was feeding 4.80V to the module.

I'm up for at least 15 days with one from ebay

Don't know why since specs said it was good to 15Vin, I guess I'll put a zener next time, so this kind of sh** doesn't happen again.

Gonna order it now, Chinese new year is coming...

By the way, I saw you cleaned and added plenty of comments to your code, very nice for a beginner to understand how things work, thank you for that.
blackmoon is online now Find More Posts by blackmoon
Reply With Quote
Old Jan 21, 2012, 04:01 PM
Registered User
hungary
Joined Jan 2011
113 Posts
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.
kile is offline Find More Posts by kile
Reply With Quote
Old Jan 21, 2012, 08:43 PM
Team WarpSquad
Daryoon's Avatar
San Diego, CA
Joined Dec 2010
6,572 Posts
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?

thread link

http://www.hacksmods.com/tag/spektrum-dsm-hack/
Daryoon is offline Find More Posts by Daryoon
Reply With Quote
Old Jan 22, 2012, 04:57 AM
Registered User
hungary
Joined Jan 2011
113 Posts
Quote:
Originally Posted by Daryoon View Post
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.
kile is offline Find More Posts by kile
Reply With Quote
Old Jan 22, 2012, 03:07 PM
flying beam
blackmoon's Avatar
through the Looking Glass
Joined Apr 2008
1,756 Posts
Excellent work Kile.

The module way is a more compatible approach.

It happens I have a Th9x but I also have a JR 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
blackmoon is online now Find More Posts by blackmoon
Reply With Quote
Old Jan 26, 2012, 02:19 PM
flying beam
blackmoon's Avatar
through the Looking Glass
Joined Apr 2008
1,756 Posts
Received my nFR24L01+ module from China.

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.

Buy this one (from eBay or elsewhere) : http://www.ebay.com/itm/170691675921...#ht_2162wt_905

It works like a charm.

Now pcb etching to complete this and fly .

I learned a lot doing this and it was fun (not destroying my harvested module tough), thank you again Kile.
blackmoon is online now Find More Posts by blackmoon
Reply With Quote
Old Jan 27, 2012, 05:26 AM
Registered User
hungary
Joined Jan 2011
113 Posts
Quote:
Originally Posted by blackmoon View Post
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 View Post
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:

Code:
void TX_Send(void)
{
	// clear the TX buffer
	nRF_FlushTX();

	// cycle the channels
	if (neChannel == 10)
		neChannel = 30;
	else if (neChannel == 30)
		neChannel = 50;
	else
		neChannel = 10;
	
	nRF_WriteReg(RF_CH, neChannel + neChannelOffset);

	nRF_WriteReg(CONFIG, vEN_CRC | vCRCO | vPWR_UP);	// TX mode
	
	// send a fresh packet to the nRF
	nRF_WriteTxPayload((uint8_t*) &nePackets[neLiveNdx], PACKET_LENGTH);

	nRF_CE_hi;		// power up the transceiver
	
	// wait for MAX_RT
	loop_until_bit_is_clear(PIN(NRF_IRQ_PORT), NRF_IRQ_BIT);

	nRF_WriteReg(STATUS, vMAX_RT);	// reset MAX_RT flag
	
	nRF_CE_lo;		// power down the transceiver
}
It's a tiny casting problem but it caused weird behavior.

Quote:
Originally Posted by blackmoon View Post
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...
kile is offline Find More Posts by kile
Last edited by kile; Jan 27, 2012 at 05:31 AM.
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
New Product Nine Eagles Solo Pro 328 (Nine Eagles' answer to the Blade 120 SR?) SoloProFan Micro Helis 1736 Aug 08, 2014 02:15 PM
Sold COX/Nine Eagles Micro 2.4 Radio system RX, TX & Motor ShokWaveRider Aircraft - Electric - Micro & Indoor Airplanes (FS/W) 1 Nov 16, 2011 09:27 PM
Wanted Nine Eagles Tx Michaelpilon Aircraft - General - Radio Equipment (FS/W) 2 Oct 16, 2011 07:19 PM
Sold Nine Eagles / Cox Extra 300 (minus Tx) dhaizli Aircraft - Electric - Airplanes (FS/W) 4 May 01, 2011 08:36 PM
For Sale Nine Eagles 210A TX, Flybar & Battery Klippie Aircraft - General - Radio Equipment (FS/W) 0 Mar 23, 2011 06:04 PM