Topic: Help re: serial communication by radio / Xbee devices (Read 12181 times)

TurboTyne · « **on:** September 05, 2014, 10:58:22 pm »

Does anyone know of a commercial radio control product for model boats etc that is capable of sending serial data such as would be needed to repeatedly send about 40 – 80 bytes of data between microcontrollers in the base unit and microcontrollers in a boat?

Alternatively, does anyone know if XBee transceivers have been used successfully or unsuccessfully to control model boats (or any other model)?

These XBee’s seem great because they connect to serial inputs/outputs and offer 2-way comms. BUT it would be very helpful to hear of any problems with these devices for model radio control before I get too carried away with investigating them. E.g. The DMS2 and DMSX protocols in commercial model radio-control products seem to have in-built safeguards because of their frequency hopping methods. I think that XBee’s use a different spread frequency method (DSSS versus FSSS) but I’m not at all clear about this and I don’t know if they would be as reliable as DMS2 devices.

In case anyone is curious, here is a long-winded explanation of why I’m asking the questions.

I am building a microcontroller-controlled steam plant, (inspired by VitalByte: http://www.modelboatmayhem.co.uk/forum/index.php/topic,15817.0.html). I am thinking about incorporating a 2-way radio link to transmit data between the microcontrollers in the hand-set and microcontrollers on the future boat. Since I already have several microcontrollers talking to each other via an I2C serial bus, it would be great to be able to control things by serial communications via a radio link. From what I’ve seen, off-the-shelf radio-control units would not be readily adaptable to serial data transmission since they are designed to transmit servo-type control signals and some binary switch signals. (Although I gather that the radio link is based on serial data transmission). Although I am a very long way from having a boat, it seems to me that, if I am going to use a radio link in the control system, it will be sensible to include it early on in the development rather than try to incorporate it later. This is because it may have a big impact on the design of the whole control system.
The range of transceiver devices called XBee transmit serially encoded data and are quite cheap (about £26 each). The XBee-Pro devices apparently have a range of two miles outdoors and are small. On ModelBoat Mayhem I have found only one post that mentions XBee’s and this was only a brief mention of the possibility of using them. That post was by Hellmut1956 (http://www.modelboatmayhem.co.uk/forum/index.php/topic,43327.msg437402.html#msg437402)

The XBee devices use 2.4 GHz with direct sequence spread spectrum technology (DSSS) and use unique 64-bit address codes to ensure the signals go to the correct receivers. Also they can be set up to re-send if a message was not RXed and acknowledged properly.

Thanks in advance for any advice.
Mike

TurboTyne · « **Reply #1 on:** November 26, 2014, 10:07:08 pm »

Well, in the absence of any more informed input here, I've spent much time searching on-line. I found one description of a model boat controlled via an Xbee link. More significantly, several people have built model planes or drones controlled via Xbee and also used the Xbee to send data such as location information and camera images back to the operator. One report said the plane control worked O.K. even alongside other planes at a crowded meeting.

If these devices are O.K. for controlling planes, where fast reliable communication is critical for avoiding a crash, then I guess they will be fine for a model boat of moderate speed. Anyway, I've invested in a pair of standard Xbees which should give an oudoor range of 300 feet. (The more expensive Pro versions work over a mile). These devices should make possible the control of an almost unlimited number of functions. Maybe I'll post more info when /if I manage to set up a working radio link, just in case anyone finds it of interest.
Regards Mike

NFMike · « **Reply #2 on:** November 27, 2014, 01:16:26 am »

Sounds interesting. I can't think that I'd use it at present, but I'll read what you post anyway.

flashtwo · « **Reply #3 on:** November 27, 2014, 09:18:23 am »

Hi Mike,

Sounds great fun and a technical challenge.

Are you talking about 2-way data flow - commands to the boat and data coming back?

Currently, as you might know, I use a cable connected (25-way parallel) control and display unit (CDU) if I need to investigate any start up problems, otherwise I don't use it.

At the end of a run, I also use the CDU for displaying run time, average RPM and maximum pressures and temperatures - this is very useful for calculating fuel efficiency and plant performance before and after modifications of the mechanical or control parameters such as the proportional and integral settings.

It would very useful to replace the data cable with a radio link and it would simplify the on-board controller and get rid of the 25-way connector.

It my case it would entail extensive modifications (though still achievable) and I agree with you that it should be done at this early stage rather than later.

I see some commercial systems communicate with laptops which seems a bit of an overkill and are not good in bright sun light. My CDU uses the high contrast LCD with backlighting (very useful for the first time last week during a late afternoon/dusk boating display).

At the early stage of my project, I was ask if steam data was to be transmitted to shore so that the gas and steam valves could be adjusted, but it was my intension to make the boat autonomous under all conditions, including pump failure and over temperature. These features have been useful over the many years of experimenting!

Good luck and its got me thinking now!

Ian.

TurboTyne · « **Reply #4 on:** November 27, 2014, 06:13:32 pm »

Thanks Plague. It will be probably be quite a while before I get anywhere with this, but I will post an update in due course.

Hi Ian
Yes, it is 2-way comms that I hope for - the Xbees can handle a fairly high rate of data. They communicate with the PICs via a standard serial bus via a UART interface. Luckily, each of the PICs I've been using happen to have a Universal synchronous/asynchronous receiver/transmitter module. The idea is that PICs on the boat will continue talking to each other via I2C bus and the XBees will form a wireless serial link between one of these PICs and a one of the PICs in the control box. As you say, one could communicate with the control-box Xbee via a lap-top but I plan to keep using my data entry and display control PICs.

I always thought your semaphore arrangement was very ingenious, but I'm not at all sure I'll get such good automatic control as you have achieved and so I'd like to be able to send more data back and forth. But, of course, getting a new feature of a PIC (i.e. the USART module) to work for the first time is sure to be an uphill struggle for me.

Regards Mike

flashtwo · « **Reply #5 on:** November 27, 2014, 11:15:22 pm »

Hi Mike,

I've just discovered the 16F877 PICs that I'm using have the UART. I would have to install one in my Control and Display Unit and battery power it.

You have to remember that a lot of my control system was developed in the shed with the steam engine connected to an electric generator to save getting my feet wet and to stay in the warm!

I developed my SPI communications (I2C seemed too complicated for me) on a separate board before incorporating it in the controller - it kept the code to a minimum and speeded up testing.

I suppose you could start with just getting the UART working between two wire connected PICs and then tackle the XBEEs.

The Semaphore - do you means the servo operated pressure indicator? I've not fitted it to the Edwardian Steam Launch, since it would spoil its "lines" and the best pressure indicator is the engine itself.

I'm sure if you got the I2C working you'll be able to tackle the UART.

Ian

TurboTyne · « **Reply #6 on:** November 28, 2014, 11:40:06 am »

Hi Ian

Yes, I think you’re right about linking 2 PICs via UART first off and inserting the Xbees later. Especially since another complication is that the Xbees can be programmed themselves (via a generic serial-USB cable). I’ve invested in the Xbees, adapters and USB cable now since they are going in my “Christmas stocking”.

It seems the Xbees can be slotted in as a simple serial-cable replacement, but to get the most out of them they should be programmed. e.g. This enables use of more secure radio connection by causing transmissions to be targetted to the unique machine address of the desired target device and by enabling automatic repeat transmission if the transmission was not received and acknowledged properly.

The Xbees do not have 0.1” pin spacing so, to use with a bread-board, you must either make a suitably designed PCB or buy an adapter board. To start with I’ve bought a couple of adapters made by Adafruit which seem better than others I’ve looked at. Two Xbee devices (XB24-AWI-001) were £18 each , 2 adapter boards were £11 each and the USB-serial cable was £13. IF

it all works, it seems to me it will be a pretty cheap basis for a multichannel 2-way RC system.

By the way, I’ve been following your posts on your Edwardian launch – a very impressive and good looking model !

Regards Mike

flashtwo · « **Reply #7 on:** November 30, 2014, 02:40:54 pm »

Hi Mike,

Now you've got me started on a project to replace my cable connection between the Control and Display Unit (CDU) and the launch with the radio link.

I've looked at the USART pin requirement and they are spare on my system.

Also, I can basically duplicate my current Display Processor, that's on the launch, into the CDU and transfer the existing data tables between them via the link. The on-board Control Processor will interface with the on-board Display Processor exactly as the current scheme. Job Done!

Now to tackle the USART (job not done!).

Which PICs will you be using?

Ian

Plastic - RIP · « **Reply #8 on:** November 30, 2014, 03:24:49 pm »

Never heard of these units before - they look really useful and simple to use.

Problem is, I can't think of a domestic use to justify buying some to play with - any ideas?

flashtwo · « **Reply #9 on:** November 30, 2014, 04:31:26 pm »

Hi Mike,

Where are you sourcing your XBees from. Maplins has a few of the modules, but not the (USB?) adaptor boards.

Ian.

TurboTyne · « **Reply #10 on:** November 30, 2014, 07:47:31 pm »

Hi Ian
I started with PIC16F818 but needed an extra something or other (can’t remember all details of my tortuous path) so was using a mix of the two types. The 1827’s use the extended mid-range instruction set which I found advantageous, but each time I switched between programming the two types I had to re-load firmware into the Pickit 3 and that was irritating. So, I modified the firmware for the three 818 PICs and now I am only using the 1827’s.
I sourced the Xbees from Farnell – see:
http://uk.farnell.com/digi-international/xb24-awi-001/rf-module-txrx-xbee-wire-ant/dp/1337912?CMP=i-bf9f-00001000
Also the serial cable:
http://uk.farnell.com/ftdi/ttl-232r-3v3/cable-usb-to-ttl-level-serial/dp/1329311?CMP=i-bf9f-00001000

Please remember I have not used any of these items yet so I cannot confirm that any of the following info is worth the memory space it is saved in.

I get most of my stuff from Farnell - free very reliable next day tracked delivery for orders over £20 and are generally much cheaper than Maplin - (but not for copper clad boards).

I read on some web site that USB-serial cables have a chip built into them that handles the re-coding of signals and these are made by a particular company (in Scotland I think). But, apparently some cheap cables use an unauthorised copy of the chip and these can give problems with some versions of Windows etc. I do not know how accurate is all this but I decided to play safe and get my cable from Farnell.

Apparently you download the free programming software from the Digi web site but I've not done anything yet so cannot speak from experience.

One complication is the large number of different types of Xbee modules. I have bought the simplest (and cheapest). The more sophisticated ones seem to mainly differ in using clever ways to net-work devices together and send data over larger distances by relaying transmissions between devices in different locations. The manual for the above Xbees can be found at:

https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Manual.pdf

I found pages describing various adapter boards (e.g. http://www.instructables.com/id/XBee-adapter/?ALLSTEPS). This one uses a clever 2-sided board from Adafruit. The circuit details are all made available but I was not going to bother trying to make a board myself (single sided is my limit) and I could not find a UK source of the PCB, so I bought 2 adapter kits from:

http://www.ebay.co.uk/itm/161362083804?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT.

These adapters can be connected to a bread board or to the USB cable. The adapters also convert the 5V power supply used for PICs etc to the 3V supply needed for the Xbee. They also buffer the logic inputs between PIC and Xbee and have LEDs to show when things are happening.

It will be ages befire I get going with this so you might well have a system set up before me. In that case I'll be able to come to you for help

.

I'll send another post with some relevant links that I came across.

Regards Mike

TurboTyne · « **Reply #11 on:** November 30, 2014, 08:00:31 pm »

Quote from: plastic on November 30, 2014, 03:24:49 pm

Never heard of these units before - they look really useful and simple to use.

Problem is, I can't think of a domestic use to justify buying some to play with - any ideas?

Hi Plastic

I hope they'll be quite easy - but from my limited experience in electronics, Murphy's laws hold true here as in other areas of life, i.e. Rule 1 - nothing is as easy at it looks, Rule 2 - Everything takes longer than you think.

Afraid I cannot suggest any domestic applications - unless an Xbee-controlled drone to spy on the neighbours would be appealing.
I've included some links below which show some examples of Xbee-controlled models / drones. There were a few more impressive web-pages but I cannot find them now and forgot to book-mark them.

Regards Mike

http://aeroquad.com/showthread.php?3297-AeroQuad-controled-by-PC-via-XBEE&highlight=control+xbee

http://www.rcgroups.com/forums/showthread.php?t=1041252

https://arduinoxbeeremote.wordpress.com/2013/02/01/building-the-arduino-receiver-electronics-for-yellow-plane/

https://antibore.wordpress.com/2010/08/27/making-of-xbee-pro-868-based-rc-controller/

http://hades.mech.northwestern.edu/index.php/XBee_radio_communication_between_PICs

flashtwo · « **Reply #12 on:** December 14, 2014, 12:56:10 pm »

Hi Mike,

I’ve made some progress with the USART comms between two 16F877 PICs, though I must admit it was a struggle.

I managed to resurrect my serial comms test board that’s been knocking about in a draw for four years and, surprisingly, it still worked!

I added the USART wires (blue and yellow in the photo) and loaded both PICs with the same display code that I use for the Control and Display Unit (CDU, the grey box).

I modified both codes, connected my PICOSCOPE oscilloscope and, relatively easily, managed to start transmitting 7 bytes of data from the CDU’s PIC.

The PIC code, that would be in the boat, was modified to receive the data and display on the LEDs. That PIC code was then changed to successfully transmit 63 bytes of data, but……….

All was going well until I tried to write the receiving interrupt code in the CDU’s PIC. I literally went around in circles with transmit, receive, transmit, receive - not being able to tell which bit of code was causing problems. I finally had to cut the yellow wire to break the loop and found it was the receiving code in the CDU’s PIC that was playing up.

Finally after five days of serious contemplation, I found that the servicing order of the receive and transmit interrupts was crucial. Unlike most interrupts the transmit interrupt flag TXIF cannot be cleared in code and has to rely on the transmit register TXREG being empty to clear the TXIF flag in hardware.

In the CDU’s code, the Transmit interrupt was serviced first and then the Receive interrupt. Well, apparently, the Transmit interrupt flag TXIF was not being cleared preventing the receive interrupt from being serviced and causing total chaos in the complete loop. By servicing the receive interrupt first solved the problem. This hadn’t occurred in the “boat’s” PIC code because I had written the receive interrupt code first.

The photos show the USART test rig, the transmitted 7 bytes (notation incorrectly states 8 ) with the Raise Steam Temp. Trip bit being sent and the 7 raise/lower bytes transmitted and 63 data bytes received.

I hope this will save you many days (weeks?) of frustration.

Now to order the XBEEs……….
A Merry Christmas to All…
Ian

flashtwo · « **Reply #13 on:** December 14, 2014, 01:17:08 pm »

I don't know how that emicon? crept in - how do you stop them?
Ian

flashtwo · « **Reply #14 on:** December 14, 2014, 01:20:17 pm »

Forget the last message - if you type 8 and ) together then

appears.

I modified the original message to separate the 8 and ) and the emicon disappeared, viz:

".....(notation incorrectly states 8 )....."

Sorry for the confusion.

Ian

TurboTyne · « **Reply #15 on:** December 14, 2014, 10:18:38 pm »

Hi Ian

Well done for overcoming the USART problem and thanks a lot for posting about it. I am sure I would have wasted more than a week over it.
It sounds like exactly the sort of crucial detail that so often causes a problem when working with PICs (well they do for me anyway).

I have not started on the radio link tack yet as I am trying to complete another project first - knowing how PIC programming will take over everything once I do get re-started on it.

I look forward to hearing how you get on with the Xbees.

Best wishes

Mike

flashtwo · « **Reply #16 on:** December 16, 2014, 01:31:09 pm »

Hi Mike,

I've been looking with a 'scope at the various flags using them to set/clear an output.

I couldn't detect any change in the TXIF interrupt flag which seems to be continuously set. I could detect the others like TRMT and TXIE.

I've finally dumped the TXIF and now use TXIE as a flag (any flag bit could do) to indicate (i.e. set) when the previous interrupt item (i.e. receive) has been serviced and then clear it when the transmission is complete. The Transmit code is then governed by the status of the TXIE flag. Using this method allows the Transmit service routine to be placed anywhere in the Interrupt Service Routine and not necessarily at the end.

My method is:

Master PIC uses TMR0 to schedule (every 0.5s) the Transmission to the Slave PIC. On completion of the data reception in the Slave, the Slave transmits the required (steam) data back to the Master where the Interrupt Service Routine handles the incoming data using the RCIF in the normal interrupt way.

I can't see anyway of using the TXIF normally as per any other standard interrupt flags.

I agree with you that the PIC programming takes over everything - its like a dog with a bone!

Ian

flashtwo · « **Reply #17 on:** December 17, 2014, 10:27:04 am »

Hi Mike,

Great success with the XBEEs!

I bought the XBEE ZB series 2, 2mW, which are the more complicated ones that can be used in a network of XBEEs – this gives the future option of operating the complete Home Fleet at the Battle of Jutland!

With a lot of help from the internet, I found that there were factory set as Routers. The one that was to be on shore I had to set up as the “ZigBee Coordinator AT” and the boat destined one as the “ZigBee End-Device AT”.
This was done by inserting each of the XBEEs in the adaptor board that connects to the PC via the USB cable. I downloaded the XCTU application and used it to load the required firmware (all variations are listed in the menu) into the XBEEs and also ensured that the each had the others unique 64-bit address.

If they are left as routers they spend ages looking for networks and the system grinds to a halt.

Now they knew that they were either a Coordinator or an End-device and each other’s unique address, I put them back in their sockets connected to the PICs and Hey Presto!

The system sprung into life and worked as if the XBEEs didn’t exist. The only difference is the slight transmission/reply delay that can be seen on the ‘scope and that’s only between 110 to 180ms.

I must admit the hardest part of all this was the TXIF and all the problems it caused.

I’m going to investigate the radio system security to ensure that interference is at a minimum – I have used the household portable ‘phone (uses a lot of 2.4 bandwidth) against the XBEEs and they still carried on working and even powered up without any problems.

I’m now going to build a new Control and Display Unit (I have spare LCDs etc.) minus the grey cable and connector. I will also end up with 10 extra I/O channels on the boat!

Well, many thanks to you Mike – you certainly inspired me to give the idea a bash and hopefully others will see the potential for model boating.

Ian.

TurboTyne · « **Reply #18 on:** December 17, 2014, 04:14:00 pm »

Hi Ian

That is excellent news!

Now I am goling to find it harder to resist the temptation to play with the PICs again.

Did you use the Adafruit adapters? I can't make out the detail in your photo.

My long term aim is to use the Xbees to control steering as well as boiler etc - so as to not need to use a standard radiocontrol TX and RX. Do you think this plan will be O.K.? Is that also your plan or will you continue to use the standard RC along side the Xbees?

Regards Mike

flashtwo · « **Reply #19 on:** December 17, 2014, 07:12:42 pm »

Hi Mike,

I used the Sparkfun adaptors from Hobbytronics, viz:

http://www.hobbytronics.co.uk/xbee-explorer-reg

.......I just soldered a 5-pin PCB connector to the adaptor board so that I could easily disconnect the wiring.

plus the USB board:-

http://www.hobbytronics.co.uk/wireless/zigbee/xbee-usb-adapter

I certainly think your plan is feasible. Currently my plan is to continue using the standard RC, because the joy sticks are ergonomic.

For servo control you can go completely digital and do away with the standard transmitted PWM and just use it on the boat between the receiving PIC and the servos - although aren't there digital servos available now?

I'm transmitting raise/lower signals to the control parameters on the boat and receiving steam pressure/temperature, feed pump capacity, gas valve servo limits etc. etc.

I'm still thinking of the whole range of possibilities that are available now, e.g. signal strength display on the LCD etc.

Ian

flashtwo · « **Reply #20 on:** December 23, 2014, 09:33:52 am »

Hi Mike,
Again a bit of an uphill struggle, but I’ve managed to integrate the XBEE code into my AE35 controller and, with the addition of just one wire in the controller, plug the XBEE into the D-Type socket.

The original setup with the CDU cable connection can be achieved by just loading the previous code.

I had a lot of trouble getting both types of serial comms (USART and SPI) to work at the same time due to the shear number of register flags to set up.

So, I’ve got USART working between the “boat” and “shore” and SPI serial link in the AE35 controller between the original display processor 16F877 PIC and the process controller 16F877 PIC.
There is an accumulative delay of about 1.5s between raising a control parameter value (digital commands) and seeing the display value change; this can easily cause an overshoot in setting the value but not unmanageable.

I’ve received a hand held case from Rapid Electronics and (after Christmas) will build the new system into it.

One thing I had trouble with was e.m. interference from my angle-poise lamp that had a fluorescent lamp in it. This caused me two hours of lost time trying to find the cause of intermittent operation of the PICs – I’ve replaced it with an incandescent lamp (I was incandescent at the time!)

The photo' shows the XBEE connected to the AE35 controller. I hope to be able to fit the XBEE into a 25-way D-Type enclosure and just plug it in when required.

Merry Christmas

Ian

TurboTyne · « **Reply #21 on:** December 24, 2014, 10:51:15 pm »

Hi Ian

It is interesting to hear about your continuing progress. But your posts also make me increasingly tempted to get started with the XBees myself. However, I really want to compete my current project first. Your Vital Byte posts caused me to become a “PIC addict” and I am now finding ever more ways of using them. (I have spent the last 7 months building a machine that I hope will enable me to mill properly shaped blades around the periphery of miniature steam turbine rotors. If the manual machine works O.K. then I plan to use PICs to partially automate the process).

Getting back to your last message, do you have any idea how much of the 1.5 second delay is due to the XBee link and how much due to PIC loop times etc? If I were to use the XBees to transmit steering commands, do you think that a similar delay would be too long for good control of a model boat – a model warship not a speed boat?

Regarding your bizarre experience with the lamp – did the interference act via the XBee radio link or was it directly affecting the PIC devices?

Have a good Christmas

Mike

flashtwo · « **Reply #22 on:** December 25, 2014, 09:08:25 am »

Hi Mike,

Just a quick message before stuffing the turkey!

The lamp interference was due to having the lamp very close to the PICs when I was trying to see where to connect the 'scope probes - the XBEEs weren't involved.

I think the 1.5s delay is 90% PIC loop delay. I've various scheduled data transfers going on - 0.6s in the "hand held CDU" and 0.5s in the AE35 controller, plus the other routines of handling the 4 servo circuits.

I did try and speed things up yesterday, but inadvertently change something that stop the entire system. It took me all day to find that I had reset an EEPROM value to zero which was used as a divisor in the division routine - so it was a case of "INFINITY AND BEYOND...."

I had made provision in the data amendment code to prevent zeros, but this one had crept in using the PIC2 programmer erasing the EEPROM memory. I modified the dividing routine to prevent this in the future.

I'm retiring to the kitchen now!

Ian

g6swj · « **Reply #23 on:** December 27, 2014, 11:27:17 pm »

Hi,
I have been following this post with interest.

You may find this useful especially his cheat sheet

Appreciate this is arduino and not pic based

Check out tutorial 5 - it shows a delay between message received and digital pin change which looks like xbee hardware delay

http://m.youtube.com/watch?v=CzH146rR-7I

Regards
Jonathan

g6swj · « **Reply #24 on:** December 28, 2014, 08:03:55 am »

Look at vid tutorial 5 at 11:45mins onwards to see delay

Regards
Jonathan

News:

Author Topic: Help re: serial communication by radio / Xbee devices (Read 12181 times)