Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[flashtwo]

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.

[TurboTyne]

 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



 

[flashtwo]

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.

[g6swj]

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

[flashtwo]

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

[g6swj]

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

[flashtwo]

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.

[flashtwo]

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.

[TurboTyne]

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

[flashtwo]

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

[flashtwo]

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.

[TurboTyne]

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