On Sat, Dec 16, 2017 at 9:30 AM, Denis Heidtmann <[email protected]> wrote:
> With this new found knowledge I noticed that the interface was set for 1 > stop bit. I set it for two, as the protocol is reported to use. It made > no difference in the behavior I observe--no response (other than the usual > delay) to the request for data. > Be aware that if you close and re-open the serial port the driver might/could/should (I have no experience but something I'd check) reset the comm parameters. So ideally the program you're talking to the port with would be the one setting the baud rate and bits so there's no chance for unintended consequences. I've lost track of how you're doing it. Ideas? Should I look for/fabricate connectors which will allow me to use > my desktop to snoop on the serial traffic? If you have a couple more serial adapters that would be great, but we shouldn't have to resort to that. :) > Or should I be looking at the > usb signals? Only if you have a USB sniffer/protocol analyzer. There's a LOT of stuff going on at the bus level that would be way too much work to sort out without one. Maybe the transmitted signals from the dmm are not getting > through the usb-serial device. > I just recalled a technique used for capturing RF packets from wireless temperature sensors utilizing the sound card input as a storage scope. If you're only running 600 baud it will be more than fast enough. All you need is a resistor or two to scale the input signal: https://rayshobby.net/reverse-engineer-wireless-temperature-humidity-rain-sensors-part-1/ Enjoy! NealS _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
