[Ubld.it StaffModerator]

hi there, rngcapture shows bytes per second. 50kbytes/s is 400kbits/s. sorry for the confusion.

[Ubld.it StaffModerator]

Just a quick google. If you look at this link:

https://www.php.net/manual/en/function.dio-tcsetattr.php

You will see the open it, set the port attributes, then read bytes from it. It’s the same as every language dealing with a serial port.
Just make sure you are reading binary data.

[Ubld.it StaffModerator]

There is a contact link on the menu. https://ubld.it/contact/ Just provide your information and we will get that handled for you.

[Ubld.it StaffModerator]

Sorry for the late reply, It means that the internal consistency check for the second generator is hitting its limit. This doesn’t mean you will get bad random numbers, but it means that it is in a spot that we wouldn’t prefer it to be in. If you could contact support with the information of where and hwen you purchased it, we would love to do an exchange to inspect what is going on with that unit and we are perfectly happy to send you another one. But to let you know, the output stream of data should have an undetectable result of that light — it *could* indicate a serious problem but usually it means the pre calibration we perform on it was too close to the wear in specs.

Staff

[Ubld.it StaffModerator]

The only thing I can think of why sched_yield appeared to fix it, was by causing a delay, and another byte was actually available for reading (that wasn’t EOF), while it did drop the EOF char and notify you. but the problem of termios not being raw was still there.

Anyway, glad the problem is resolved.

[Ubld.it StaffModerator]

So while googling for possible causes, I found your stackoverflow post

If sched_yield fixes your issue then I would say go with that. One thing I can think of is to either try this code on a PC (take out the raspberry pi aspect).

Another other would be check your termios settings (tcsetattr/getattr) (this is why I asked about using the udev script). Since the TrueRNG outputs full binary, If the termios settings aren’t raw, and its set to canonical mode, then I believe the tty would eat the EOF character, alert ppoll, but cause read() to return 0 bytes read (according to https://stackoverflow.com/questions/358342/canonical-vs-non-canonical-terminal-input).

Of other note, make sure you don’t have modemmanager package installed, we’ve seen cases where it will open the port, change the tty settings, and do stuff while you are using the port (It’s noted somewhere in the docs or forums). We added some stuff to udev to disable it, but there is a case where newer OS updates don’t allow that setting or something any more.

[Ubld.it StaffModerator]

Hmm, I assume that ppoll is returning a positive number ? What is your timeout on ppoll ?

You are using the udev script correct ? What happens if you don’t use your program, you just do something like cat /dev/TrueRNG > /tmp/file or using pv instead of cat (to see the rate) ? I’m just trying to make sure the TrueRNG is operating normally.

The only signal that would stop the flow on the TrueRNG is the DTR signal. If you are some how toggling DTR (on USB it’s virtualized and not a hardware pin but it still works) it will stop/start the flow. The random number generator never stops generating, but if DTR goes away it throws it in the trash instead of over the USB bus.

[Ubld.it StaffModerator]

I realize this is an old thread, we had some issues with the web site getting exploited and all the settings messed up so we weren’t getting notifications.

—

Are you still having issues with this ?

[Ubld.it StaffModerator]

8-bit values may be concatenated to get larger numbers or truncated to get
smaller numbers.

For example, if you have 0-255 this is 0 to 0xFF or 00000000 to 11111111 in
binary.

If you want the 0-31, you can simply AND with 0x1F to get the required
range:

in C this is
outValue = inValue & 0x1F;

If you want a larger power of 2 then you just concatenate to the required
number of bits and AND with the number of bits you want to have,

For 4194303 (2^22-1) in C this is:
outValue = ((inValue1 << 16) | (inValue2 <<8) | inValue3) & 0x3FFFFF;

The simplest way to get another integer range is to concatenate the number
of bits required to get a higher number that you want then discard all
values above it (this is ok, since every value is equally probable).

For 2456743 in C this can be done like this:

tempValue = ((inValue1 << 16) | (inValue2 <<8) | inValue3) & 0x3FFFFF;
/* Gives a value between 0 and 4194303 */
if(tempValue <= 2456743) /* only use if <= the required range */
{
outValue=tempValue;
}

There are more efficient methods of doing this but are dependent on the
application (Google will help you with this).

[Ubld.it StaffModerator]

Your data sample set is too small for dieharder, we typically run it with 10-14 gig of data. If oyu look at the top you see:

” # The file file_input_raw was rewound 48 times ” comment.

When it rewinds, it thinks it sees a pattern. This is documented in the dieharder documentation.

Other devices may pass if they filter out these failures prior to
providing the data (especially if pseudorandom). But, for a true hardware
random number generator, some failures are expected.

Read the snippet here https://cockrum.net/electronics.html

[Ubld.it StaffModerator]

redneonglow,

The units calibrate according to the specific characteristics of the noise generators to provide the best results. On the first batch of noise generators, their characteristics were within the published range. Other batches of boards have different characteristics due to component tolerances. This reading is for troubleshooting issues with the power supply. You should only be concerned if it’s under 6000mv or above 12000mv or you see large changes of over 2000mv on a single PC in a short period of time. Also, the units will stop output if the noise generators are not functioning properly.

[Ubld.it StaffModerator]

Mouscap,

We use a python script to change the modes. Check out this blog post: https://ubld.it/how-to-use-truerngpro-with-python-in-windows-10-and-linux/

If you scroll down a bit to the example script the mode change is happening around here:

print('================== Debug Mode ====================')

# Put the TrueRNGpro in Debug Mode

# Knock Sequence
ser.baudrate = 110
time.sleep(0.1)
ser.baudrate = 300
time.sleep(0.1)
ser.baudrate = 110
time.sleep(0.1)

# Set Mode
ser.baudrate = 2400 # debug mode
time.sleep(0.1)

# This clears the receive buffer so we don't print binary data
ser.flushInput()
ser.flushInput() 
returnline = ser.readline()
ser.flushInput()

# This labels our columns for readability
print("RNG1 RNG2")
print("_____ _____\n")

# Loop
for _ in range(debugloops):
 try:
 returnline = ser.readline() # Read a Line from the TrueRNGpro
 print(returnline) # Print the result to the console
 except:
 print('Read Failed!!!')
 break

print('================== Normal Mode ====================\n')

# Return back to Normal Mode

# Knock Sequence
ser.baudrate = 110
time.sleep(0.1)
ser.baudrate = 300
time.sleep(0.1)
ser.baudrate = 110
time.sleep(0.1)

# Set Mode
ser.baudrate = 300 # normal mode
time.sleep(0.1)
ser.flushInput() 

# Set Data Terminal Ready to start flow
ser.setDTR(True) 

# This clears the receive buffer so we aren't using buffered data
ser.flushInput() 

Ubld.it

[Ubld.it StaffModerator]

Haven’t messed with Arch much, but that sounds about right. Typically the rng-tools daemon (rngd) points to /dev/hwrng by default. So yeah get the udev rules in to make /dev/TrueRNG. Get the rng-tools package. Modify the conf file to point to /dev/TrueRNG.

[Ubld.it StaffModerator]

Yes the TrueRNG v3 works fine with the Raspberry Pi.

[Ubld.it StaffModerator]

Sorry, I didn’t see this post until now.

Creating bitmaps can be done in various ways. Most programs that will accept RAW you just import as a raw file and describe it to the program, such as 8 bit mono (would be 1 byte per pixel) or raw rgb would be 3 bytes per pixel (in rgb format).

Photoshop, the gimp, these programs should work fine.

For the easy button you can just use imagemagick which is available on most Linux platforms.

First the image size; lets say we want a 640×480 image. Thats 640×480 bytes, now if we want it in rgb format, thats 640x480x3.

So using your calculator (or bc on the commandline)

you can do

echo “640x480x3″ | bc
The response is 921600

So we need 921600 bytes to make a 640×480 image in rgb format.

Capture using ‘dd’

dd if=/dev/TrueRNG of=/tmp/image.raw bs=921600 count=1 iflag=fullblock

(iflag=fullblock is important)

This will capture 921600 bytes in the file /tmp/image.raw

Now using ‘convert’ from imagemagick

convert -depth 8 -interlace plane -size 640×480 rgb:/tmp/image.raw /tmp/image.jpg

Now we have a 640×480 jpeg of random rgb values.

————–

For audio you can do similar things like using the program audacity you can import the audio as raw, and specify how many channels and bit depth. Same as the image, if you wanted 16khz audio 2 channels, you need 16k*2 bytes per second of audio.

You can also do funny things like catting /dev/TrueRNG to /dev/audio or piping it into sox or aplay to play the audio. Sox will accept raw input and convert to wav files based on your parameters.

Hope this helps

[Author]

Posts