Sorry, no. The symptoms you describe look, feel, smell and taste like the classic win32 textmode conversion. If the module is ensuring that none of Perl's IO layers, nor the C runtime layers are exercising an influence upon the datastream, then I cannot see where the problem would lie.
My instinct says that the OS, CRT or PerlIO layers *must* be getting involved somewhere in the chain and treating the datastream as text instead of binary. Not that it isn't possible for a different explanation, but the obvious one is usually right.
A few thoughts.
and then arrange for the device to send it's binary data?copy COM1 /b data.in /b
Basically, you need to track down where the datastream is being modified. If this is a real serial port, then I'd try attaching a Serial Port analyser to the connection. I used to have a blue cable with a built-in patch box and LEDs that could latch on byte at a time. It's probably in the loft somewhere, but I cannot remember the brand name.
Alternatively, you could try monitoring the port with on of the many free software analysers that are available on the net. Once you are convinced that the same data that is leaving the device is being received, then you move up to the module itself.
Try enabling debug on the module. If that shows the data being received from the device driver correctly, then make a copy of the module for backup and then go in and add some trace statements and see if you can find where the modifications are being made. If the problem is in the DD, you're faced with trying contact the supplier and find out if there is a later version, or some IOctl that you can set to disable it. And so on.
Sorry that's not much help. I last used the module on my old laptop under NT4. It seems to have moved on quite a bit since.
In reply to Re^4: How to get right data from COM1 using Win32::SerialPort
by BrowserUk
in thread How to get right data from COM1 using Win32::SerialPort
by Chenny
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |