What kind of test equipment to analyze serial data packets? - Page 1
Forum section: electronics / testgear

author: e100
author_rank: Frequent Contributor
timestamp: September 10, 2016, 01:27:00 pm
content: I found out the hard way that eyeballing waveforms on a basic scope is too hard when you have to wade through 20ms long packets looking for subtle timing errors or truncated bits.Are there any not-too-expensive tools can detect these kinds of problems, or do people just make their own from scratch, or buy expensive add-on modules for high end scopes?Mike

author: DTJ
author_rank: Super Contributor
timestamp: September 10, 2016, 01:31:40 pm
content: Maybe a bus piratehttp://dangerousprototypes.com/docs/Bus_Piratehttps://www.sparkfun.com/products/12942

author: nctnico
author_rank: Super Contributor
timestamp: September 10, 2016, 01:35:16 pm
content: There are several USB logic analysers suitable for this purpose (not the Intronix Logicport though because it doesn't have enough memory) assuming the problem isn't in the analog domain. Also: what kind serial stream are you looking at? If it is a generic protocol a good scope with protocol decoding doesn't have to be expensive (say around $1000 if you want to avoid the bottom of the barrel equipment).

author: kripton2035
author_rank: Super Contributor
timestamp: September 10, 2016, 01:41:13 pm
content: a hacked ds1054z around $400 will do the job of decoding serial data.

author: bobaruni
author_rank: Regular Contributor
timestamp: September 10, 2016, 01:43:36 pm
content: If you want something that will do 16 channels at about 20MHz using the cheap STM32F4 Discovery board, try logic discovery and a SUMP-compatible logic analyser client:https://code.google.com/archive/p/logicdiscovery/

author: e100
author_rank: Frequent Contributor
timestamp: September 10, 2016, 01:56:46 pm
content: Quote from: nctnico on September 10, 2016, 01:35:16 pmIt's just a serialised struct which goes via a uart and Max485 driver onto a half duplex RS485 bus. I found that getting the sender and receiver to talk without stepping on each others toes requires sub-millisecond control of the Tx and Rx enable lines otherwise data gets truncated before it has fully left the driver.

author: Fungus
author_rank: Super Contributor
timestamp: September 10, 2016, 02:04:45 pm
content: Change the protocol so that the slave only talks when you ask it to (by sending a data-request byte). Then you shut up until the slave has finished sending.No RX or TX enable needed!

author: nctnico
author_rank: Super Contributor
timestamp: September 10, 2016, 02:56:56 pm
content: Quote from: e100 on September 10, 2016, 01:56:46 pmSome UARTs have built-in RS485 transmit enable logic. Otherwise you'll need to check whether the TX buffer is empty (or get an extra interrupt). Either way using a UART over a half duplex RS485 connection is daunting. Last time I implemented something like that I checked the received data for corruption and stop if it happened. I also used a delay after receiving data before sending data onto the bus. That allows the transmitter time to disable the driver and release the bus.

author: e100
author_rank: Frequent Contributor
timestamp: September 10, 2016, 03:43:33 pm
content: Quote from: nctnico on September 10, 2016, 02:56:56 pmCurrently I wait for the UART to says that it's empty, then I wait an additional 100 us before disabling the MAX485 Tx circuit. If I don't add the delay then sometimes the receiving node isn't able to decode the packet.I also add a 1 ms delay to any reply packets so there is a definite "dead time" when neither party is transmitting.

author: AndersJ
author_rank: Frequent Contributor
timestamp: September 10, 2016, 05:01:31 pm
content: www.fifo.se

author: voltsandjolts
author_rank: Unknown
timestamp: September 10, 2016, 05:34:27 pm
content: QuoteThat might not be enough. Maybe you are (checking a flag || getting an interrupt) that the transmit *buffer* is empty and ready for the next byte.... but that can happen when there are still 10 bits (8N1) about to send from the actual transmit register. Just a thought but you might want to check the micro datasheet.

author: nctnico
author_rank: Super Contributor
timestamp: September 10, 2016, 05:59:37 pm
content: Either way this problem is best debugged/verified using an oscilloscope because the signal levels can give a clear indication of a collission event.