I have usb device (trueRNG) producing random bytes (comparable with a ‘mad modem’). I am using the serial control to read it. It works fine under Mac but it fails under Windows. I found the proper port number and initialize the port as follows:
W_serial.Serial1.SerialPort = system.serialport(portnumber)
W_serial.serial1.RequestToSend= false // don’t request data yet
W_serial.Serial1.Baud=W_serial.Serial1.Baud9600 // or 2
W_serial.Serial1.Parity=W_serial.Serial1.ParityNone // or 0
W_serial.Serial1.Bits=3 //8 bits.
W_serial.Serial1.Stop=W_serial.Serial1.StopBits15 //or 1
if (W_serial.Serial1.open)=false then
msgbox(“failed to open the RNG”)
else
W_serial.Serial1.close 'and close again
end if
The error event in serial1 produces a msg box. To read I ope the port, set requesttosend and wait in a loop till the data-available event is triggered. On Windows I find the port number using different code but after that I use the same approach to read. However the serial1 error event fires immediately upon trying to open the serial device. Of course the open method then returns a failure.
What can be wrong. On the Mac it works without a driver. Maybe the lack of specification of serial1.InputDriverName is the culprit. I have no experience with windows (don’t know how drivers are installed and how in general drivers are referred to). But it could be a totally different reason. Dick
Hi Tim, It is already after utilizing (as given in the first six lines of code) when opening the serial1 control (the line: if (W_serial.Serial1.open)=false then…) that the windows version responds with the serial.error event and indeed returns false because it was unable to open the serial device. I suspect it may be that I have to specify a InputDriverName (although this is apparently not required for MacOS). Si I don’t read any thing yet.
What do you think might be the reason for this different behavior between MacOS and Windows?
Hi, I have reduced the code to the minimal. Actually only the following:
Serial1.SerialPort= System.SerialPort(0) 'device is connected to port number 0
Serial1.open
The second line triggers the error-event in the serial1-control with an error code ‘5’. I am not sure what this means (most probably a break-condition or a framing-error?). I have tried all values of the serial1.baudrate property. All of them have the same error. I used no-parity, 1 stop-bit as is specified for the device (trueRNG).
I am now compiling on a windows machine rather than my mac. Interestingly I have also asked the drivername and on Mac as well as on Windows that is returned as a portname (e.g. on windows \\.\COM5). Whereas I expected ‘usbser.sys’). So what can it be?
Does RNGCapture work from their site? Its a console app that you can use to test the device in windows to find out if its a Xojo issue or a driver/setup issue (just like someone is having on the forum there at the moment). Just a thought.
Hi Julian, RNGCapture didn’t work. And it also confused me because it says: Portnumbers are numerical so rather than COM50 use 50. But any number above the ‘NumberofPorts-1’ gives an out-of-bounds exception error by XOJO. So far I have used portnumber=0. Because the Friendlyname of that port 0 yields ‘truerng’. It is also the first in the list of ports that are detected by RNGCaprure.
We now work on the assumption that some other app opened the port without closing it and the operating system is confused. So we rebooted that Windows machine. I will report if that helped.
Still rather curious about using port numbers over the numberofports resulting in out-of-bounds error. Maybe a problem of XOJO? Or is the doc of the RNGCapture app nonsense.
I would contact ubld.it
If you look at their forum, their driver doesnt seem to always “just work”. If you were not able to “read” the device with their software (RNGCapture), you have little chance to do it with Xojo (or any other serial terminal). They have a list of recommendations on their forum, i would start with those- http://ubld.it/forums/topic/problems-with-truerngpro-on-windows-10/ )
It would help to know what they are using for their serial/USB inteface chip. Most common is the FTDI interface which is generally quite reliable, but occasionally has some issues. Other interface chips can be very flaky.
On a mac, you can run this code to see what is connected to the USB ports:
Public Function GetUSB() as String
'Return a list of USB devices
'Mac only
Dim My_Shell As New Shell
My_Shell.Execute "system_profiler SPUSBDataType"
return My_Shell.Result
End Function
Looking though the returned result, you should get enough information to determine the actual hardware. For example, a USB device using an FTDI interface chip returns this:
[quote] UMFT230XB:
Product ID: 0x6015
Vendor ID: 0x0403 (Future Technology Devices International Limited)
Version: 10.00
Serial Number: FTXW43GN
Speed: Up to 12 Mb/sec
Manufacturer: FTDI
Location ID: 0x14100000 / 6
Current Available (mA): 500
Current Required (mA): 90
I have to apologize, because all problems were gone after rebooting the windows machine. Apparently the serial port with the connected USB device (trueRNG) had been opened by some other software and hadn’t been closed or released properly. Since I am testing remotely it was only after failed testing with the company provided software (RNGcapture) that I realized something might be wrong with the machine itself ad had to aks the ‘owner’ of the windows machine to reboot.
Glad you got it sorted, just remember to