Model Boat Mayhem
Technical, Techniques, Hints, and Tips => Radio Equipment => Topic started by: 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 (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 (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
-
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
-
Sounds interesting. I can't think that I'd use it at present, but I'll read what you post anyway.
-
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.
-
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
-
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
-
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
-
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
-
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 Mike,
Where are you sourcing your XBees from. Maplins has a few of the modules, but not the (USB?) adaptor boards.
Ian.
-
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 (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 (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 (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 (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 (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
-
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://aeroquad.com/showthread.php?3297-AeroQuad-controled-by-PC-via-XBEE&highlight=control+xbee)
http://www.rcgroups.com/forums/showthread.php?t=1041252 (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://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/ (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 (http://hades.mech.northwestern.edu/index.php/XBee_radio_communication_between_PICs)
-
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
-
I don't know how that emicon? crept in - how do you stop them?
Ian
-
Forget the last message - if you type 8 and ) together then 8) 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
-
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
-
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
-
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.
-
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
-
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
-
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
-
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
-
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
-
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
-
Look at vid tutorial 5 at 11:45mins onwards to see delay
Regards
Jonathan
-
Hi Mike / Jonathan,
I've 'scope the various signals and between the last byte leaving the "on shore" PIC and the first byte responding back from the "on boat" PIC the delay is a minimum of 96.54ms and a maximum of 196.31ms - so that is the send/return delay which comprises two radio transmissions.
The delay between the start of transmission from the "on shore" PIC and the start of reception at the "on boat" PIC varies between 20 and 110ms.
The spread of delays is caused by the "on boat" PIC handling other interrupts to do with the SPI serial data transfers with the other "on boat" PIC.
Stripping out the effects of the PIC's interrupt handling routine, I think the XBEE transmission delay is in the order of no greater than 20ms, and that may still be function of the interrupt routine.
To find out the meaningful XBEE delay I will have to write a minimalist Interrupt Routine dealing just with the USART interrupts.
I think that for purely controlling the boat there shouldn't be any significant delays at all, but introducing lots of additional processes on the boat will have to be at a lower priority to the control function.
Thanks for pointing to the YouTube video which was very informative.
Ian.
-
Hi Ian and Jonathan
Thanks for the link Jonathan, that series of videos looks very useful.
I have only looked at the video briefly so far and also I’ve not yet read much of the XBee data sheet. But I am puzzled by the fairly slow delay in switching the LED on/off in the video. To me, this seems much slower than the delays indicated by the your very useful scope measurements, Ian. Do you agree that your delays are much shorter than the LED changes shown in the video? I gather that, in the video, the LED is controlled from XBee digital output pin 4. This is in contrast to Ian’s signals being relayed via the USART bus. So, is it the case that the serial bus operates faster than the output via the analogue and digital XBee connections?
Regards
Mike
-
Hi Mike,
I've disconnected the output (Dout) of the receiving XBEE to the "boat" PIC, so there is no Interrupt software involved, and measured the time delay between the input to the transmitting XBEE and the output from the receiving XBEE.
The delay goes through a pattern of approximately 20, 40, 60 and 80ms (sometimes 100ms) in about 0.5s steps and then repeats. I can't see any relationship with the PIC's code (its physically disconnected), so it must be something in the XBEE internal processing.
So, I think the baseline delay for the control system should be 100ms as a worst case.
More research required.
Ian.
-
Ian,
I hope I did not introduce a "red herring" as I realise now that you where not setting digital pins on the xbee. I was really shocked though with the example in uTube vid 5 where such a simple process too so long - I love xbee's but whilst they are amazing they clearly do appear to have some drawbacks.
I'll keep following your progress with interest as you venture forwards with your amazing project...
Regards
Jonathan
-
Hi Mike/Jonathan,
Found this article so far....
https://www.kickstarter.com/projects/1101297082/r10-quadrotor-powerful-inexpensive-and-customizabl/posts/378158
Doesn't explain why my one goes in a step sequence of delays.
Ian
-
Ian,
The latency pattern is very strange - definitely got to be a good reason for your observations.
A few words come to mind as a gut reaction but not based on any fact - sleep? / power save? / polling more (non existent) devices?
Found this doc but think it's pitched a little higher than my level of understanding! I had a couple of attempts to digest facts but still over my head - indeed could be completely unrelated!
The only thing I glean is that it doesn't suggest much latency
http://www.digi.com/support/kbase/kbaseresultdetl?id=3065
Can you monitor on your scope what is happening to the Sleep RQ / On Sleep pins - are they changing at all with a similar pattern - also what is happening to CTS pin?
Regards
Jonathan
-
Hi Mike / Jonathan,
The new XBEE Control and Display Unit is up and working in its new case (despite Christmas - baa humbug!).
Amazingly, the new XBEE CDU worked first time, apart from – wait for it – the display was upside down ~#! I had to turn the display around and remake all sixteen soldered connections to the display and then retest it (luckily the wires were long enough, but the screw holes are now in the wrong position).
The new case has resilient soft corners, ideal for use by the pond side.
I’ve incorporated a couple of slide switches for regularly used functions– one for boiler filling, the other for future use.
Being a menu driven device, all possible functions on board the boat could be selected from the display screen.
I’m just waiting for some AAA rechargeable batteries and some high current slide switches, and then I’ll do some range trials.
The old CDU can still be used if I reload the old software.
Again – a great idea of yours Mike.
I’ve still to look into the latency/delay mystery – it is not going to stop the device from working, but it would be nice to know why it goes through that regular 20, 40, 60, 80ms pattern.
Ian.
-
Hi Mike,
Here's a photo' of the XBEE mounted in a 25-way D-type enclosure and plugged into the AE-35 controller.
I've done some initial range tests and the system has maintained comms through three brick walls and out in the garden - I'll do some more once the batteries are recharged.
The red LED on the hand held CDU now blinks every time (0.5s) on a "receive" from the "boat", which itself responds to a " receive" from the "shore", thus indicating a complete data loop (shore-to-ship and ship-to-shore) is active.
I hope to be exhibiting at the Ally Pally (London) next weekend on the North Kent Model Boat Display Team's stand.
Ian.
-
Hi Ian
That all looks brilliant and I especially like the new control and dislay unit.
Are you using the PRO- type of XBees with the greater range or the lower power type?
Have you encountered many (any) other people using PICs to control steam plants?
Hopefully you'll get a lot of interest shown at ME exhibition. Pity I'm so far away.
Your progress has prompted me to at least plan how I'll incorporate an Xbee link. This will entail a fair bit of reorganisation of firmware between PICs, but no major new code blocks, apart from that needed for the USART connections. I've attached a diagram of my current system and 2 diagrams to show how I currently envisage the system will be when I eventually get around to using the XBees.
Any suggestions will be gratefully received.
Regards
Mike
-
Hi Mike,
Comments much appreciated.
I'm using a pair of XBEE 2MW S2's, i.e. the 2mW version.
Yes, there are a few people out there attempting to use PIC based control systems - some on full sized steam launches and on models, here's one:-
http://www.thesteamboatingforum.net/forum/viewtopic.php?f=8&t=1067
One difference between our systems is the PIC functions. Your feed pump PIC is used for measuring the RPM and controls the speed, whereas mine just measure the RPM and passes the value to the main PIC which does all the control - just different solutions to the same problem. I must do some diagrams like yours for documentation if for no other reason.
In the boat located AE-35 Controller I have three identical software PICs measuring the two pumps and engine RPM (supported by a Schmidt trigger IC processing the raw Hall Effect signals), one Timer PIC outputting 200us and 2000us external timing pulses to the RPM PICs, one 877 PIC doing all the control functions and finally the now much underused 877 PIC interfacing with the XBEE. This last PIC used to do all the processing to support the LCD, which is now done the New CDU. The underused PIC now has lots of available I/O for future use.
I've attached another photo' of the New CDU - why do we call it a "wireless" solution!
You can see I have to "fold" the two halves together therefore the wiring mustn't be too "tight". Most connections have shrink-on sleeving, where necessary and the AA batteries are just temporary until the AAA batteries arrive.
The 16F877 PIC is on the left with its 4MHz crystal, 5v regulator, LCD contrast pot. In the centre is the XBEE and on the right space for the AAAs.
You can see from the printing on the back of the LCD unit why I got confused with the orientation - the top of the display is nearest the pen. Also, in the photo' is the on-off slide switch and battery charging input.
Ian
-
Hi Mike,
Just an update on the use of XBees.
For my Voice Command System, I ordered a pair of XBee Pro S1, because they had a more power than the ones I’ve used for the telemetry system, 63mW compared with 2mW.
On reading the data sheet for them, it appears that for European use, the power output must be reduced to the 10dBm setting (i.e. 10mW).
This is confirmed by the Offcom document “IR 2030 - UK Interface Requirements 2030 Licence Exempt Short Range Devices” page 21, IR2030/1/22.
( see http://stakeholders.ofcom.org.uk/binaries/spectrum/spectrum-policy-area/spectrum-management/research-guidelines-tech-info/interface-requirements/IR_2030.pdf ).
The default power setting for the XBee Pro S1 is 18dBm (i.e. 63mW). The power setting is available via the PL command available in the free download, which connects the XBee to your computer’s USB port.
Setting up the XBee is relatively simple.
Connect the remote (or End Device) to the USB port first.
Make a note of its address high and low values, not forgetting the two leading zeros (it is better to cut and paste into a Word document, since they are a long sequence).
Set the power to 10dBw at the PL prompt.
Check that it is an “End Device”.
Next replace the “End Device” with the XBee that is to be the master or Coordinator.
Using the menu, define it as the "Coordinator".
Set the power to 10dBw.
Enter (cut and paste) the End Device address.
Voila – install and use with the UART Tx and Rx terminals of the PIC.
Note: on power calc:
Power in dBw (i.e. power referenced to 1mW) is:-
10* log(TmW/1mW) where T is the power in mW. e.g. 10*log(63/1) = 17.993 i.e. 18dBw
I hope this is helpful.
Ian.
-
Hi Ian
Good to hear another update and thanks for the very useful additional info.
I'm still a long way from using my Xbees. (Since Christmas hobby activity has been sacrificed to the task of completely re-fitting our bathroom, but I'll soon be back onto the more interesting tasks).
Your voice control plans and thread are great. I guess this gives the possibility of lots of control functions without getting bogged down with loads of knobs and switches.
By the way, I came across your thread about usb microscopes the other day. Very interesting. This gave me the idea that one of these devices could be very useful for observing the action of my home-made mini-milling machine for cutting steam turbine blades. It uses cutters 0.8, 0.5 and even 0.3 mm diameter and for those sizes, my old eyes need all the help they can get to see what's going on.
l hope you keep posting updates and l look froward to hearing about the first Xbee pond trials.
Regards Mike