- The original C application which I based the driver on does use this setting.
Ack, this is a good sign :)
I did the CHIRP driver development on a Mac, and missed this setting, probably due to the fact that I didn’t see any issue with the default setting for some reason.
Sorry, I forgot this was yours. I'm kinda suspect of anything modern that isn't 8N1, but I know there are some.
- A couple of weeks ago, a user reported a bug where he is getting bad responses from the radio. He was using windows….
After looking into it and trying to use a windows machine, I got similar errors / “ garbage” bytes back from the radio, digging a bit deeper and going back to the original C app mentioned above, I found the stop bits setting being the cause of the problem.
After the fix, reads and writes work both on my Mac and windows machines as well as for the user who reported the bug (on a windows machine).
I still do not understand why/how the Mac is agnostic to this setting and whether it is a pyserial Mac vs windows implementation or something in the “com port” OS framework.
Yeah, definitely confusing. Does this radio use a cable with the USB chip in it, or is the USB-to-serial device inside the radio itself? If the latter, then it's possible that the radio defaults the right settings and the MacOS drivers aren't actually overriding them, but the windows ones are. That's less likely if it's a generic cable, of course.
Anyway, as long as it seems consistent with the OEM software, then that's fine, I just want to make sure,
Thanks!
--Dan