MCU, signal jitter within a range of 0,1..0,2ms. Is it acceptable? - Page 1
Forum section: electronics / general

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 10:52:23 am
content: Hello,I faced with an issue. It seems there's a huge output signal jitter of MCUhttp://pdf1.alldatasheet.com/datasheet-pdf/view/19897/PHILIPS/PXAS37KBBE/+0JJ98UL.hKpRudTch/1CGTLMR+/datasheet.pdf. The output signals are TTL to UART signal itself and transmission enable signal.I measured timing range of jitter, it's something 0,1..0,2 ms. Is it normal behave?thanks in advance!An Update:purple trace -drive enable;blue -reply;green -comming query;It shows how comming reply stop bit is being processed by MCU. There's a huge jitter there.For clarity's sake a query is being sent every 2 sec.Yellow trace is differential line B+

author: David Hess
author_rank: Super Contributor
timestamp: July 01, 2019, 11:32:12 am
content: You did not show exactly what you measured but the answer is probably in the name. UARTs are asynchronous and depend on a relatively low frequency clock for timing.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 12:02:11 pm
content: Quote from: David Hess on July 01, 2019, 11:32:12 amIf it's based on asynchronous stuff, it doesn't mean that you may reply when you wish 200us earlier or later. Such looser behaviour may cause bus collisions. Don't it?

author: RoGeorge
author_rank: Super Contributor
timestamp: July 01, 2019, 12:15:26 pm
content: UART has distinct lines for Rx and Tx, and it is a point to point bus, so you can not have collisions on a UART.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 12:22:36 pm
content: Quote from: RoGeorge on July 01, 2019, 12:15:26 pmit needs to think bigger. The UART may go further to diff.bus (e.g. half-duplex).

author: David Hess
author_rank: Super Contributor
timestamp: July 01, 2019, 12:27:21 pm
content: UARTs are commonly used with multi-drop buses like RS-485.What I mean is that internally the UART uses a clock which operates at a small multiple of the baud rate so timing resolution is relatively course compared to the external clock and any signals.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 12:31:06 pm
content: I did an update of #1. Animated GIF.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 01, 2019, 12:55:33 pm
content: That's Ok. Only the timing within characters (relative to the beginning of the start bit) is important. The transmitter can start sending at any time. If it wasn't that way, you would have to have super accurate clocks.If you have huge peer-to-peer network, use CAN. Its timing also matters only within packets, but CAN has collision detection/negotiation mechanisms.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 01:02:35 pm
content: Quote from: NorthGuy on July 01, 2019, 12:55:33 pmI would bet. Due to "That's Ok", we have a bus collision while usage half-duplex variant of RS-485.We are stuck for a month.

author: langwadt
author_rank: Super Contributor
timestamp: July 01, 2019, 01:36:15 pm
content: Quote from: CiscERsang on July 01, 2019, 01:02:35 pmhow can a delay of a few bits on a byte(s) response cause collisions?sure the jitter isn't caused by your own software ?

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 02:00:54 pm
content: Quote from: langwadt on July 01, 2019, 01:36:15 pmThat's the point, the delay doesn't cause a collision. If response occurs earlier, that causes a collision. So, I need to slow down that, some way.Unfortunately that's not my software, otherwise I would have fixed this issue long ago.

author: mikerj
author_rank: Super Contributor
timestamp: July 01, 2019, 02:31:21 pm
content: It looks like you are talking about about the latency between an outgoing frame and an incoming one. Assuming this is an interrupt driven scheme, interrupt latency can vary considerably depending on how the code is written e.g. are interrupts disabled for critical sections, are interrupts nested and what are their priorities?If it is important (and it very often is not) then this latency is something that needs to be included in the software design decisions on one or both sides of the link.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 02:42:27 pm
content: Quote from: mikerj on July 01, 2019, 02:31:21 pmSay, the huge jitter gives an opportunity to see, or so to speak, gives an advice, how to solve the problem. If it's delayed for some reasons, we haven't a collision.

author: hans
author_rank: Super Contributor
timestamp: July 01, 2019, 02:54:09 pm
content: The jitter of software running on an MCU can jitter due to so many reasons.One would be the asynchronous arrival of data and synchronous activation of certain software tasks. For example, the UART receive interrupts puts data into a FIFO quickly. Processing is activated by a timer task. It depends on a lot of parameters to say what is an acceptable result.I assume that early processing leads to 2 bus drivers being "transmit enable" at the same time, thus causing a collision event. Is the other bus collider more in your control? You maybe can resolve the issue there.(Nonetheless, I would argue that functional behaviour that depends on magically tuned timing is not the way to go though)

author: NorthGuy
author_rank: Super Contributor
timestamp: July 01, 2019, 03:12:57 pm
content: Quote from: CiscERsang on July 01, 2019, 02:00:54 pmCould you give some more details. Looks like you have a device which transmits something on the bus, then expects the response, which comes too early. For some reason, your transmitter is still holding the bus when the response comes. Is this the correct description of the problem? What prevents you from releasing the bus earlier?

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 03:20:14 pm
content: Quote from: hans on July 01, 2019, 02:54:09 pmI don't have an access to both firmwareBoth manufacturers answered exactly the same stuff.Quote

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 03:27:51 pm
content: Quote from: NorthGuy on July 01, 2019, 03:12:57 pmGood point. As I wrote above, I can't decrease time after stop bit by Master. I can't delay response by Slave. What the manufacturers said, see previous post.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 01, 2019, 03:39:51 pm
content: Quote from: CiscERsang on July 01, 2019, 03:27:51 pmSo, you don't have any control of any of the devices. Is there anything you can control? Do you have an ability to add any extra components on either side? change baud rate?

author: langwadt
author_rank: Super Contributor
timestamp: July 01, 2019, 03:48:24 pm
content: Quote from: CiscERsang on July 01, 2019, 03:20:14 pmwhich suggest that what you think is an issue isn't, and you should look for something else

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 03:48:44 pm
content: Quote from: NorthGuy on July 01, 2019, 03:39:51 pmThe master has a set of parameterization command (baudrate, parity, 7 or 8 bit frame, one or two stop bits).The slave has less parameters. I tried different baud rates. No success. That's not a root issue.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 03:52:49 pm
content: Quote from: langwadt on July 01, 2019, 03:48:24 pmMy dear, that's my hope. So I'm asking here. Guys give me a few minutes I will prepare a picture called ''bus collision".Perhaps someone tells me something useful on this picture.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 04:09:11 pm
content: Updated, find a new pic at #1.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 01, 2019, 04:57:16 pm
content: Quote from: CiscERsang on July 01, 2019, 03:48:44 pmLooking at your new picture, that's exactly what you think it is. The "Master" holds the bus for too long. The signal is still Ok, but I'm afraid the "Master" is not listening until it releases the bus. Therefore tweaking the signal with pull-ups/pull-downs is ulikely to help. This is definitely the "Master"'s problem. There's no reason for the "Master" to linger on the bus after the stop bit expires.The best settings would be those which would get "Master" from the bus sooner. Certainly 1 stop bit is better. There's a hope that at the highest baud rate the hold period will be shorter - you can measure on your scope. Although the "Slave" is not a slouch, and may speed up the response too.If settings don't help, you need to change hardware. Since you could read the "Slave" enable signal, I would guess the "Slave" and its tranceiver are physically different ICs. If so, it might be possible to install a delay device on the transmit line between the "Slave" and its RS-485 transceiver - sort of a small MCU which will re-transmit everything with a small delay.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 05:54:19 pm
content: Quote from: NorthGuy on July 01, 2019, 04:57:16 pmUnbelievable. We are speaking about completed devices which are produced serially by wolrd known companies.I asked both for custom firmware, they told me that there's no need and it's impossible.Probably they also have an outsourced development somewhere in Bangalore.As concerned the master: Unlike to the slave, it's quite tough to get driver IC leads, due to PCB specific design.My ideas are:to perform the same measurements as I did on the master's PCB, to see timing correlations;to find out what IC is used as a driver in order to study its behavior and so forth;BR

author: NorthGuy
author_rank: Super Contributor
timestamp: July 01, 2019, 06:22:59 pm
content: It is relatively easy to separate your devices into two different RS-485 networks. A simple MCU in the middle will work as a bridge: will re-transmit the data from "Master" to the "Slave" and back introducing necessary delays. All you need is a single MCU and two RS-485 transceivers.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 06:36:16 pm
content: Quote from: NorthGuy on July 01, 2019, 06:22:59 pmPay attention to what the slave's MCU stands for. Most of time this device transmits values which gets from its A/D, the faster the better.Simple I faced with trouble at the beginning while parameterization of that device (distorted response). That's the point.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 01, 2019, 06:43:39 pm
content: Quote from: CiscERsang on July 01, 2019, 06:36:16 pmRe-transmission will not decrease throughput, only will add some latency.Your scope shots don't look very fast. What's you baud rate?

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 01, 2019, 06:53:37 pm
content: Quote from: NorthGuy on July 01, 2019, 06:43:39 pmStill, there's no need. I have to fix parametarization first. So it is used 19200. However I'm stuck at this phase.Also please take a look at slave's homemade el.diagram attached. The output part.BR

author: NorthGuy
author_rank: Super Contributor
timestamp: July 01, 2019, 07:50:19 pm
content: Quote from: CiscERsang on July 01, 2019, 06:53:37 pmThis is not fast.Quote from: CiscERsang on July 01, 2019, 06:53:37 pmVery strange design. The left part looks like TTL to RS-232 level translator and then the RS-232 is passed to the right part, which appears to be an RS-485 transceiver. It is not clear why they didn't use the RS-485 transceiver capable of working with CMOS levels directly. If the rest of the device is designed this way, perhaps you'd be better off re-designing the whole device from scratch.

author: langwadt
author_rank: Super Contributor
timestamp: July 01, 2019, 08:38:27 pm
content: Quote from: CiscERsang on July 01, 2019, 06:53:37 pmwait what? that is just wrong, from ttl to rs232 and then some resistors to make work with a ttl level transcieverI assume they swapped A/B to get the data polarity right, but why?

author: rstofer
author_rank: Super Contributor
timestamp: July 01, 2019, 09:49:55 pm
content: The transmitter should release the bus and the previous receiver should stay off the bus for about 1 bit time. 1ms at 9600 baud.This is the bus turn-around time.http://www.ti.com/lit/wp/spry265/spry265.pdfIt is likely that the line control signals are generated in code and depending on processor speed and interrupt handling, this won't be very precise. Unfortunately, the receiver that is about to become the transmitter has no way of knowing that the previous transmitter is hanging onto the bus.One way of handling bus contention is to listen to what you are sending. If there is a mismatch, a collision has occurred and the transmission should be aborted and the entire packet resent.Given that you don't have control of the software on either end, you're in a jam.I would show the scope traces to the manufacturer that messed up the transmitter code.If you have a working unit, compare the traces...

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 01, 2019, 10:20:42 pm
content: Quote from: CiscERsang on July 01, 2019, 03:48:44 pmCan the link work at 7 bits ? You could try that ?TX looks a bit slow releasing the bus, but is in idle state at that time. Problem, is, an early-active fights that late-idle.If you cannot get into the boards, and have to make something work, a possible work around would be to OR wire the RS485, which means you drive active with diodes, and pull passively to idle.(that's how CAN bus works, it is differential, but avoids this dual-driver contention by only pulling one way)A diode in parallel with a moderate resistor (maybe 1K) allows the resistor to pass the RX direction, but not pass so much of TXThat means overlaps of idles are ignored, only actives matter and in this case, you are ok from the scope display.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 01, 2019, 10:23:22 pm
content: Quote from: CiscERsang on July 01, 2019, 06:53:37 pmHow much of that circuit is inside the manufactured unit, and how much is added on outside (by you?)

author: NorthGuy
author_rank: Super Contributor
timestamp: July 01, 2019, 11:01:44 pm
content: Quote from: PCB.Wiz on July 01, 2019, 10:20:42 pmI don't think you can improve the situation by tweaking the bus. With 90% probability, the first transmitter doesn't listen to the bus until the bus is released. Therefore, what happens on the bus during the hold is of no consequence. In fact, OP does get half-decent signal from the second transmitter while the bus is held by the first transmitter (see his animation), but this doesn't solve the problem.

author: langwadt
author_rank: Super Contributor
timestamp: July 01, 2019, 11:26:23 pm
content: Quote from: NorthGuy on July 01, 2019, 11:01:44 pmyeh with /RE and DE tied together, only delaying the slave data will work

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 02, 2019, 01:01:29 am
content: Quote from: langwadt on July 01, 2019, 11:26:23 pmIt depends from the #1 which is the slave node. The scope captures show the master in that test is the errant one. (slow master release)Quote from: NorthGuy on July 01, 2019, 11:01:44 pmMaybe.. easier to test than to guess. The OP sounds like he has limited options....

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 02, 2019, 01:59:32 am
content: Quote from: NorthGuy on July 01, 2019, 07:50:19 pmIt's so designed to provide the customer different variants of communication, such as pure RS232 and RS485 (half-duplex).BR

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 02, 2019, 02:02:29 am
content: Quote from: PCB.Wiz on July 01, 2019, 10:23:22 pmI changed and added nothing there at all. Everything in original state.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 02, 2019, 03:18:14 am
content: Quote from: CiscERsang on July 02, 2019, 01:59:32 amHow big is the rest of the board? If it is not too complex, may be you can make your own.You certainly can try to modify it. Say, you can try to replace the RS-232 translator with a pin-compatible MCU which re-transmits the data with a delay. But it is all manual work. I don't think it would be worth it unless you have very low quantity.IMHO, if you want to keep the old board then an external re-transmitter is the only option.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 02, 2019, 04:53:07 pm
content: Quote from: NorthGuy on July 02, 2019, 03:18:14 amThe small sub-PCB 15x10 comprises MCU with belongings and MAX232. The base-PCB comprises RS-485 driver and power supply.Yes, I can keep the sub-PCB and newly rebuild the base PCB. It's possible, thus I get so-called OEM-device.Quote from: NorthGuy on July 02, 2019, 03:18:14 amYou know this is small part of project of automation. We and our partners acquired some components for testing in this project. We paid money for completed devices which are produced serially.In this area, as a rule of thumb, all used components mustn't be OEM. Also, it's supposed to be maintained by local personnel. That means that the customer will be able to purchase and replace faulty, e.g. master or slave, by itself. That's a two-way street, so to speak.Btw, what IC will be able to play a role of a delay (200us, for example)? Do we have IC with such option, available on the market?BR

author: NorthGuy
author_rank: Super Contributor
timestamp: July 02, 2019, 05:13:10 pm
content: Quote from: CiscERsang on July 02, 2019, 04:53:07 pmThere are special delay lines ICs, however I'm not sure there are any which can produce such huge delays as 200 us.I would just use a simple MCU. All you need it to do is read from one UART port and pass the byte to another UART port - this will produce reasonable delays automatically. It also need to maintain DE line during writes, which is also very easy. Any MCU with enough pins (and preferably one or two UART modules) can do this.Or, perhaps, if you tell the vendor that you will only buy their devices if they add a delay option, they may cave in.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 03, 2019, 12:39:09 am
content: Quote from: CiscERsang on July 02, 2019, 04:53:07 pmA small MCU with 2 uarts would give a point solution. (not so easy to change baud, * char quantized delays, so ~ 520us at 19200 )At low baud rates, a small MCU with software delay line could also work, or if you want to avoid any code, a HEF4557 1-to-64 Bit Variable Length Shift Register is an IC.200us at 19k2 is 3.84 bit times , sampling ~10 times per bit, needs ~38 bits of storage, and a 192khz clock.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 03, 2019, 04:39:17 pm
content: Guys, I don't know exactly which way this slave operates.so, there are doubts on:for example, so-called interactive mode when parameterizing. A programm command query <-> corresponding reply. Here, nothing bad will happen, due to this is just interractive mode;Since it's primarily A/D, it must broadcast its values in real time or very close to it. So, I don't know whether an implemented delay will undermine that ability or not, while broadcasting.hope I expressed a thought understandable.BR

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 03, 2019, 07:42:50 pm
content: Quote from: CiscERsang on July 03, 2019, 04:39:17 pmIs that a question, or an operating observation ?Quote from: CiscERsang on July 03, 2019, 04:39:17 pmThat' why you would make the delay as small as is needed to fix the issue.You mentioned slave HW, do you have access to the master HW, or will you modify every slave ?Did you try all the supported baud choices, in case there was a sweet spot ?

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 04, 2019, 07:02:16 am
content: Quote from: PCB.Wiz on July 03, 2019, 07:42:50 pmjust observation.Quote from: PCB.Wiz on July 03, 2019, 07:42:50 pmYes, I agree, the most reasonable way is modification of MAster, by means of firmware alteration or HW, if possible.As concerned Master's HW: There are difficulties there too. Unfortunately its PCB is designed not the way when you have an easy access to both sides of PCB.I was able to get an access to one side only.To get an access to another side requires a desoldering of quite long PCB connector (as it is shown below).As concerned Master's shematics:As it turned out, it is quite well designed in terms of safety. When I saw MAX845 on accessible side, a first thought was, both, master and slave are using similar IC types.But no such luck, The MAX845 I found wasn't a driver that is connected directly to AB lines. As it turned out, it plays role of a driver for special power supply which ensures an isolation from differential line.So, I still can't even take traces from DI, DE leads of true transmitter. Also I failed to find at least an example sheme where there are participants such as an isolation transformer (HALO), its driver, and transmission driver.BR

author: NorthGuy
author_rank: Super Contributor
timestamp: July 04, 2019, 01:27:35 pm
content: Even if you don't want to design your own, perhaps you can buy a different board from a different vendor, or a different flavour, such as CAN?I bet these board are sold for exuberant price. You pay them big money so that everything works out of the box. And it doesn't.You certainly confused their support teams when you represented the delay as some sort of jitter. Try again. Be more specific. Tell to the master's support that their device holds the bus for too long. Tell to the slave's support that their device responds too fast. Make them work for your money.

author: CiscERsang
author_rank: Regular Contributor
timestamp: July 05, 2019, 04:21:59 am
content: Quote from: NorthGuy on July 04, 2019, 01:27:35 pmThat's the point, we can't.Quote from: NorthGuy on July 04, 2019, 01:27:35 pmOf course this not a board from Aliexpress or ebay.Quote from: NorthGuy on July 04, 2019, 01:27:35 pmNo, I presented them the issue not as a jitter. I just sent them bus collision traces and wrote that the Master holds line too long and slaves response too fast and I need either service parameter or FW alterations. There wasn't any word about jitter or so.I was amazed, when they asked how much we are going to buy for the future projects.I doubt that my mail was forwarded to true developers/engineers. it was just seller, having nothing to do with bits, frames, traces and so forth.My idea if they consider us as a big enough client we will get the green light. That may mean FW update and so on. I know how it works.BR