Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 12:54 16 Mar 2026 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : RS232 TTL SIGNAL GENERATOR

Author Message
OA47

Guru

Joined: 11/04/2012
Location: Australia
Posts: 1043
Posted: 12:12am 16 Mar 2026
Copy link to clipboard 
Print this post

I have a project that uses a Pi Pico to generate a TTL RS232 SIGNAL STREAM and has proven very handy over time. I wanted to incorporate a signal sniffer to identify the rate and bit length of a signal under test. I have used a sample and test procedure that will go through each data rate from 150 to 921600, 7 or 8 bits and 0-2 stop bits. The software tests for a string of ascii characters and when a match is found it reports that rate and bit length. The issue is that it takes an enormous time to accomplish if the sample is at the end of the sweep.




To improve efficiency and accuracy I have thought about measuring the average frequency of the bit stream and honing in on the bit formation of the stream. Rather than rely on AI, I thought BSI may be much more helpful so I was wondering if there could be some input in structuring a routine to accomplish the task.

OA47
 
rrroonn

Newbie

Joined: 08/02/2026
Location: Australia
Posts: 10
Posted: 01:36am 16 Mar 2026
Copy link to clipboard 
Print this post

I think I would capture some pulses, the shortest pulse should give the baud rate away.
If all else fails, remain flexible and maintain a sense of humour
 
phil99

Guru

Joined: 11/02/2018
Location: Australia
Posts: 3075
Posted: 02:27am 16 Mar 2026
Copy link to clipboard 
Print this post

CSub LOG would have been perfect for that as it captures the timing of every transition in a bitstream in an array. However it (and most CSubs) is version specific so you would need to compile it for the firmware version you are using.

Another option is the PULSIN() function. Load 2 dozen or so negative pulse times into an array then repeat with positive pulses.
The baud rate can then be calculated from the shortest pulse.
The longest high pulses (for TTL) may indicate the gaps between bytes. The number of shortest pulses that could fit between those gaps might be used to calculate the total number of bits.

Bytes that are all 1 or all 0 may scupper that idea so would require testing.
 
Print this page


To reply to this topic, you need to log in.

The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2026