Having trouble staying connected.

I have 2 xbp24-awi. I’m just wanting to use them as a direct line replacement to my serial cable for tuning ecu’s. I read through the documentation and have an understanding that they sould work in this function by default. But the way they are acting is like they just can’t keep up. The tuning software connects and disconnects continuously. I’ve set the baud rate as fast as it will go and it is still not fast enough. With a lower baud rate it won’t even connect. Help!!!

ecu = European Currency Unit? No, probably not. Engine Control Unit perhaps?

If the latter, a quick google suggests that they may have some very strange baud rate requirements such as starting at 5 baud (yes, five baud!) and then switching to the equally non-standard rate of 10400. Is that the case in your situation, and if so how are you arranging for the XBees to keep in step with what the unnamed software is doing to the serial port?

Or does ecu mean something else entirely?

Yes you’ve got the right idea. The ecu I’m using runs at 115200. I’ve got one xbee hooked directly to the serial connections on the processor not through the 232. The other is hooked to the computer with an ftdi ttl232r serial to usb converter cable. Cable works fine by its self. I didn’t know anything about keeping the xbee in step with anything. I’m new to this as you can see and am trying to learn as I go.

Ok, that makes things clearer - thanks!

If the ecu always runs at 115,200 baud then there’s no need for keeping the XBee in step with baud rate changes because there are no changes. In theory you should be able to set both XBees and your PC’s serial port to 115,200 and all will be fine. Well, so much for theory…

In practice there are a couple of issues and one of them may be a serious problem.

First question: does the ecu run at exactly 115,200 baud, or does it run at an approximation to that nominal rate? Thing is, the closest the XBee can get to 115,200 is 111,111 baud and people have reported in the past that the two rates are not quite close enough for accurate transmission. (Shameless plug: if you haven’t read my pinned post on the subject, now might be a good time to do so. You’ll also find a very similar explanation in the cookbook - see the other pinned post.)

The possibly severe problem is that to make the communication reliable the solution is to set the ecu to send two stop bits. If you’re lucky the ecu may already be programmed to do that. If you’re unlucky, it may not even be possible. In the “unlucky” case all may not be lost: maybe the XBee could be set to the next higher rate that it can achieve, and then it would become the one on which to set two stop bits. I’ve never done the sums on that one - has anyone else tried it?

Likewise, if the other XBee is attached to a PC you’ll want to set the PC to send two stop bits. That can definitely be done as far as the PC itself is concerned; whether the software you’re using will allow it is a separate question. Is the software proprietary or is it under your control? If proprietary, does it have that feature?

Alternatively, if you can change the baud rate on the ecu to a lower value that would also solve the problem.

The issue would reduce in importance if data in each direction was only sent in short bursts. I’m guessing that isn’t the case, because otherwise it’s hard to see why the manufacturer of the ecu would have chosen such a high baud rate in the first place. Am I right in that assumption?

The other issue is flow control. If the data rate is such that the PC can’t keep up, or that the XBees can’t at all times achieve the necessary over-the-air throughput, then you’ll need hardware and/or software flow control in order to avoid data loss. The question then becomes: what does the ecu support in this area, and what does the software you’re using support? Of course, the sub-question is also: is the data rate in fact high enough to make this an issue in the first place?

Well, that’s a few more questions to consider and because I know nothing about the ecu or about the software you’re using I don’t think I can go any further at this point.

Please don’t be put off - or at least, not yet. I’ve described some issues that may need to be addressed, but there’s no reason yet to assume that they can’t be.

And if we can’t fix it here in the forum, the expert folks at Digi support are resourceful, helpful and friendly. It’s often a good idea to discuss problems like this in the forum and then if no solution emerges to take it directly to them. That way the discussion will already have provided a lot of the detail they’ll need. Right now, I think we’d all need to know a bit more about the transmission capabilities of the ecu and of the software you’re running.

this may help.



Yes, that looks good. You get the source code for the embedded end, so presumably you can read that to check the stop bits and set them to 2. The source code should also tell you the situation regarding flow control. I didn’t see a distribution of the current source code for the PC software so you may need to check with the distirbutors over that.

For reliable communication you should set both the embedded code and the PC code to send two stop bits and you should check whether flow control is advised. Once that’s done I can’t see any reason why it shouldn’t work.

There is just one other thing that you could try in the meantime, and that is to try a setting of 125,000 baud on the XBees with them sending two stop bits (use the ATNB=3 command). There are no guarantees that this will work - I haven’t tried it and I’ve never seen any indication that anyone else has. In theory it just might, which is as far as I’m prepared to go! Electrical interference would reduce the chance of success, and I imagine you have a fair bit of that around. This setting is less optimal than the 111,111 baud setting.

success!! I can actually change the baud rate of the ecu. Changed that to 57600 and all is good. Thank you so much for your help. I’m still going to work with them to get to the highest baud I can. It seems to be a littl sluggish at 57600, but it works. I do have the source code. I’ll check it out and see.