DIY custom 2.4ghz RC radio system for robotics

Ok, that explains it. I did notice that my charger only took about 30 minuttes to charge it with a 1C (1,6 Ah) rate.

The second time I charged it, (after posting my Q’s) i lowered the max charge rate to 1Ah and this time my charger took 135 minuttes for a complete charging. Sounds like the battery was able to receive much more “juice” this time.

Thanks for information.

I’ve not tested the range, but I doubt it would be any trouble for robotic use.

BTW:
Do you know if its possible to use the AR7000 receiver without using the slave receiver? I tried to use it without it, at first it didn’t work but after about 1 minute it started to work again!? :confused:

I also tried to BIND the DIY and the AR7000 without the slave receiver, it worked but I still had to wait for about a minute…

I think I read somewhere that the receiver will work without the second receiver module. Can’t remember where.

I know robots don’t need a large range, um unless they do. lol :smiley: Really I’m just wanting to see what sort of range the radios are getting, that’s all. 8)

This project has been very fun to be a part of! I have learned a great deal about what’s possible with standard off the shelf components. At the same time I’ve gotten the bidirectional communications bug from Kurt.

Looking at Zigbee modules which at the lowest power level can work indoors up to 400ft. At data rates up to 250kbaud. My question is concerning baudrate, error checking and correction, and how much data can be sent with serial data. For example I know with the DIY radio that 7 channels of data with 1uS resolution and a range of 1000 can be sent in 23uS. When you move the stick on the radio the value changes in what appears to be real time. If all we have to utilize is the serial data stream, can it “keep up” so to speak?

Without getting too far ahead of myself I would like to make a system that has the ability to be expandable to more than 7 channels of data, so I need to know the bandwidth is there.

Interesting topic,

I really doubt you would see a propagation delay…

why not send the code twice or 3 times?

what about send the code with a check sum calculated on the fly…?

As for more then 7 channels of data, I think the term “channel” has to be looked at a bit more closely, your sending it serial data you have as many channels as you need, I think the limitation is the transmitter/receiver …

You think about just using a serial transmitter/receiver combination that way you don’t have to take data -> convert it to PWM then go back to code… “SEEMS LIKE A LOT OF STEPS”

I would try and see if there is some form of serial transmitter receiver combo on the market “Granted I know these aircraft 2.4ghz transmitters receiver’s have gotten like a million times better then what they were 10 years ago” and the range is stupid good.

… Here I go off on a tangent…

You think its possible to develop sort of a reverse SSC32 board?
“take a receiver and connect it to some inputs and then that serial data is piped out of some pins?”

Kurt – I haven’t had a chance to look at that code you made yet “not like I would understand it anyway” I still need to obtain my servo extension wires so I can mount my Futaba R168DF receiver to my Phoenix

…Infact here’s an idea you think its possible with new code to the ssc32 you could actually have it accept inputs? so then you can feed the input pins PWM data and it gets translated to serial code rather then have the ATOM chip handle the pwm–>data conversion?? It would basically take kurt’s code and somehow someone would convert it to work on the atmel chip “somehow”

Not sure if that ssc32 board is even able to do something like that , sure would be a lot of input channels! and if that’s the case the board wouldnt even have to be re designed, would be pretty scheweet.

Anyway those serial transmitters did a quick google search and check this out http://www.globalspec.com/FeaturedProducts/Detail/BlackBox/900MHz_Serial_Transceivers/39818/0[

Not sure if you needed bidirectional communication, although I remember seeing something on parllax’s website that worked something like 400 feet? I would put a link but it looks like there website is borked.

Either way my 3 cents for what its worth, or just to toss some more ideas into the mix o ish.

–Aaron]()

Sorry about that :wink:

My guess is we will have plenty of bandwidth for this. To do the simplist conversion we simply send 2 bytes for each of our current channels. Obviously we could convert the keypad to a single byte as we only have 17 values.

We can then experiment with different communication protocols. Things like maybe only send information on what changed. This could be with a simple 1 byte header with one bit for each channel and then only send the bytes for the ones that are set in the header byte…

I will start my experiments soon. I have a few XBees and a few Xbee Pros, some version 1 some version 2. What I did not know when I ordered them before are there are different types of nodes. End points, Routers, etc. Also did not know that there are different network meshes for them. So I found a needed the capability to reprogram the XBees. The PC USB board should arrive tomorrow. :slight_smile: The fun will be we can setup up repeaters(routers) to extend the range.

Kurt

These might be neat to do something with
http://www.sparkfun.com/commerce/images/products/09032-03-L.jpg

and at only 4 bucks each you could put a bunch of these on that DIY remote!

who posted that ultimate controller a while back? :slight_smile:

Hi Jim and all,

Very impressive piece of work you have there! Quite a lengthy thread, nevertheless it gives a great insight to the lastest radio transmission technology (and great code guide).

I have been working away from home for some time now. Got some spare time nothing to do, and have been spending the pass weeks reading through the thread and codes.

I’m thinking of getting a 2.4ghz module as well when I get back. I’ve been checking out some of the online local store in my area. Apparently none of them carry the AR7000 module, they only have the receiver.

Then, I found this Corona 2.4ghz 8-channel, and cost half the price of AR7000. Only downside is that it only has 1 Rx (which is fine since we aren’t interested in operating >10m)

It was manufactured to support Futaba and JR. I suppose they read the same signal as Spektrum(?) Any idea?

Finally got some nice weather so James and I did a little range test. The bot was still under control after 200 yards! That’s almost two full blocks! It could have gone farther but I got tired of walking! James was so far away the robot looked like it was 1/4" tall. He couldn’t even tell which direction it was going toward the end. The humidity was very low. Yup! 200 plus yards! 8)

As per a request by Xan I wrote a version of the DIY transmitter code that used a timer (in this case wtimer) to generate the pulses that go to the transmitter. This should allow for some minor interrupt processing to happen, without throwing off the timings. Not sure if it is an improvement for normal use, but here is a version of the function GeneratePulses.

[code];------------------------------------------------------------------------------
; Generate Pulse function
;
; Variables used: ChanVals array has the pulse widths in us

GeneratePulses:
#ifndef DO_OLD_WAYS
; fudge the values. It looks like the transmitter may not fully accuratly take
; the signals in and give them out 100% correctly. So try to fudge…
for iFudge = 0 to 6
ChaVals(iFudge) = chaVals(iFudge) - 2 + (ChaVals(iFudge)-988)/70
next

output DM8PPM
; The DM8PPM pin should already be configured for output...
; This is P15 on BAP which is P87 on the underlying H8/3694
; transistion to assembly language.
; fist setup loop counters and the like before we manipulate the IO port

; we will use TimerW to do our timings for us.  The idea is that 
; we will configure it to increment on every 8th clock so .5us.  We will then keep track of what time
; we will expect a transistion, and then do it when we make or exceed that time.  This should keep
; us on track whenever some interrupt handler might eat some of our time.

TCRW = 0x30					; divides the clock by 8

; transistion to ASM.
mov.l	#CHAVALS:32, er3	; er3 has pointer to our array of desired values
mov.b	#7, r2l				; r2l has count of how many channels we wish to output
bset.b	#7,@PCR8:8			; make sure set to output, basic should have done earlier!

xor.w	r1, r1				; zero out the clock count.  this will be compared to the TCNT   
mov.w	r1, @TCNT:16		; zero out TCNT to start off with.
bset.b	#7, @TMRW:8			; make sure the clock is running.
bset.b	#7,@PDR8:8			; (L8)set P15 high (Low over head here 26)

_MP_LOOP:
add.w #400, r1 ; Value the timer should go up to for this high pulse

_MP_HIGH_PULSE_LOOP:
mov.w @TCNT:16,r0 ; get the current count
cmp.w r0, r1 ; see if we got to the desired time
bgt _MP_HIGH_PULSE_LOOP:8 ; still more to go.

bclr.b	#7,@PDR8:8			; (H8) Go low again - so high overhead here (26)
mov.w	@er3+, r0			; Get the wait time in uS
sub.w	#400, r0			; (L4) subtract off our high pulse widths..
shll.w	r0					; Multiply by 2 to get to .5uS to match timer scale
add.w	r0, r1				; calculate the new transistion time

_MP_LOW_PULSE_LOOP:
mov.w @TCNT:16,r0 ; 6 get the current count
cmp.w r0, r1 ; 2 see if we got to the desired time
bgt _MP_LOW_PULSE_LOOP:8;4 still more to go.
bset.b #7,@PDR8:8 ; (8)set P15 high before testing to see if we are done to keep timing correct

dec.b	r2l					; (L2) decrement our counter for how many items to output
bne		_MP_LOOP:8			; (L4) still more channels to output

; loop is done, need to do trailing pulse

add.w	#400, r1			; Value the timer should go up to for this high pulse

_MP_LAST_HIGH_PULSE_LOOP:
mov.w @TCNT:16,r0 ; get the current count
cmp.w r0, r1 ; see if we got to the desired time
bgt _MP_LAST_HIGH_PULSE_LOOP:8 ; still more to go.

bclr.b	#7,@PDR8:8			; (8) Go low again


; will fall through to return and transition back into basic
return[/code]

As before the pulse widths may need to be slightly tweeked in order to get it to match… Also could also tweek this code slightly to test for .25uS instead of .5uS but would need to either use the overflow bit of the timer or reset the counter…

Kurt

Interesting thread! Thanks for the URL Jim.

So any plans to manufacture? Reselling the RF module shouldn’t be a problem, or you could simply tell people where to buy it.

I’m following the XMTR side, but what’s on the RCVR side? Do you just recover the 7 (not 8?) channels with an Atom Pro PWM measure command or something similar?

Looks like I’ve missed all the fun! But then I was pretty busy over that period of time.

Alan KM6VV

We got um.

lynxmotion.com/Product.aspx? … egoryID=46

It’s a fun project! 8)

Hi Alan,

Actually it looks like they now sell the RF module:lynxmotion.com/Product.aspx?productID=676&CategoryID=46. The hard part is getting the gimbahls. I think I saw a differnt thread where some people were trying to make their own and went up and buying some used modules up on ebay…

On the receiver side, you can use the pulsin command to read them in, this can eat up a lot of the processing time, especially if you don’t guess at the right order to do the pulsins. You should read every other one in the order they are received, such that by the time the basic finishes processing the first pulse, and gets to the next pulsin, the pulse had not already started or you have to wait for a whole RC pulse cycle. That is why I wrote an assembly version where you can pass in an array to hold all of the pulse widths and a bit mask showing which pins you are interested in. Works pretty well, but you still have to go for a complete RC cycle… I think the code is up there on this thread, could be on a few others…

But it would be nice if you did not have to worry about it and had a receiver that simply knew what all of the values were and you could query it when you needed it. That is why for example Zenta used two processors on his phoenix… That is why I think it would be fun to try it using something like xbee, maybe I will take it up again.

Kurt

Great!

Any other components available? I don’t recall seeing any joysticks, keyboards, or slider pots. Although I probably have all that stuff laying around.

Didn’t ketch what the receiver side had in addition to the dual (?) receivers (Diversity?). 7 PWM channels to decode?

In a robot I custom built and just shipped, I used a Superdroid board to decode receiver channels to run four PWM motor drivers and also operate a pair of relays. Are you doing something similar?

Alan KM6VV

Hi Kurte,

Yeah, Jim just sent the URL. I probably saw it when he announced it, but forgot.

Good joysticks I’ve got. I’ve interfaced them before. I like the idea of being able to get into things for a XMTR, but I’m interested in a digital link, rather then sending several channels of PWM. Then data could be sent as well. XBee would be a thought.

Thanks for the comments on reading the PWM into the uP. Sounds like a good candidate for a slave process over I2C.

Alan KM6VV

Sorry for joining this forumn so late and probably asking real basic questions. I am wanting to build a very similar remote and I have been going through the posts trying to figure out the basics without being too familiar with the atom. I wish to build something a lot simpler and am not planning on using the atom, just a microchip programmed in C or PicBasic. I don’t
need to to use the keypad or do any manipulation at the receiver side. I just want to make a custom transmitter and plug servos into the AR7200.

My understanding is I have to send 8 channels of data to pin 1 of the module. The thing I am confused about is the 400uS pulseouts (are they high or low) and the pause statements (are they high or low). The data is a pulse ranging from 1000uS? to 2000us? with a 400us pause between each channel that is subtracted out (is the 400 some randumn number Spektrum choose to distiguish the leading edge, can it be a different number?). Then I repeat the loop every 20 to 23mS? So I guess my primary questions is what should the pulses look like going into pin one of the module. Is the Spektrum looking for rising or falling edges to start counting? What are the max and min values for each channel? Do you need to send all channels? What is the max and min for repeating the loop? Sorry for a million question in one thread…

Thanks for any help with this matter, hopefully I will come back with some progress, but likely just more questions :smiley:

Hokay… A good place to start is with the pulse stream generation. For an understanding of what is happening is to look at the code. The pulses were being created on pin 15 (at least on the earlier versions), which was made low early in the program. That means the pulses are positive going. :wink: So at the beginning you create a 400uS pulse. But the time for the first position starts at the beginning, so you subtract 400uS from the desired pulse and pause that long. When that time elapses you create another 400uS pulse, then pause for the desired position (minus 400uS), etc. What you end up with is illustrated below.

Well I have like 5 minutes to finish this diagram, it ain’t looking good. I will give it a shot tomorrow. :blush:

Ok here’s the diagram! 8) It’s pretty self explanatory, the pulses are 5vdc forgiving.

rcpulse1.gif

The connections to the module are very simple.

Pin 1 = Signal
Pin 2 = Power (have tested at 5vdc ok)
Pin 3 = Ground

Air Mod…
lynxmotion.com/Product.aspx? … egoryID=46

If I understand the question right, that you want to generate the 8-servo waveform, then I’d suggest using two interrupts, one at a 2.5 mS rate in which you get the “current” servo channel, and load the PWM time into a second timer (generates 2nd interrupt) that times out to stop the pulse. The cycle repeats, and the next servo channel is serviced. Quite easy to generate 8 servo signal this way, or to toggle eight output pins to control eight servos directly.

Alan KM6VV

Thanks, I think I got it all now. I am going to start playing with my own code and save up for the AirMod. Should be a fund project :exclamation:

Please let us know how it goes. We love to see DIY radios. 8)