XR232USB - True Random Numbers @ USB
This ain't yet another ultimate, ultrafast and all-too-miniaturized USB-gadget.
It is the "official" USB-version of the XR232-TRNG, taking advantage from the benefits
of USB, but retaining fundamental XR232-philosophy of independency, security,
transparency and compatibility.
- Virtual COM-Port
- MCU features balancing, random-pooling, blanking out EM-disturbance
- Entropy source of electronic noise
- Compatible to the XR232-protocol
- Delivers random data of demonstrably good statistics
- Console tool and DLLs provided for Windows and Linux
- Safe random data rate
up to 230.400 bps
The XR232 is a true random number generator
device that delivers independent random data to a host computer. The XR232
utilizes simple, rugged and thoroughly tested circuitry and open-source software.
A fundamental (and virtually unique) feature of XR232 is the consequent use of regular
RS232 access schemes.
That is to say, we don't make use of creepy bitbanging or direct hardware access techniques.
All communication with an XR232 device is performed via standard RS232 transactions.
Unfortunately, the genuine RS232 ports have become a rare commodity on today's
PC-platforms. Many current mainboards or laptops will rather provide multiple
offers great deal of interfacing variety of hardware
(including crashdown and bluescreen opportunities as well)...
But, positively, it's quite nice to see properly installed USB devices just
doing their job with compareably fast transfer rates, hot-plugging, flexible driver
mounting, and last but not least, the option to directly use 5 volts of power
supply for many USB appliances.
XR232-enthusiasts encouraged me to adopt USB-functionality to the
project to open new fields of application and usability to a random
number device. Well, I agree, but developing GOOD random number
generator for USB is not a trivial task, despite all the fancy stuff on
the market... Our usual suspects advertise with precious boxes or
stylish sticks, and without any doubt, those hightech gadgets will have
the very latest technology from space research and quantum physics on
board. Seems the're full carefree-packages with mighty mysterious
drivers, colourful windows applications and stunning certificates for
the monied and superstitious... (Uh, and with backdoors for the
Still looking for a serious, transparent, open source and
affordable TRNG-solution on USB? You will likely come down to one of
the very few noncommercial, honest and freely documented projects, grab your soldering iron and make your own...
BTW, here's my proposal for the long awaited USB-variant of XR232
- USB-COM. We refrain from fooling around with software
USB-emulation on a µC and selfmade driver stuff. Instead we make use of a dedicated
interface chip that's optimized for RS232-to-USB conversion.
The FT232 from FTDI has it all. USB goes in, RS232-TTL-levelled signals
come out at the other end. The appendant driver offers Virtual COM ports at the
host system. They seem pretty reliable at both Windows and Linux platforms.
Those FT232s have been tested in the field for many years with stupid
applications - now its ripe enought one for the XR232 ; -)
- Microcontroller. The small but strong ATtiny85 directly
connects to a FT232's TXD/RXD lines and emulates the XR232-Protokoll.
But much more of its computing power is used however for random number
production, balancing and safety mechanisms. Like classic XR232,
entropy comes from a separate source of electronic noise. The program
in the µC (firmware) provides algorithm for optimized
extraction of entropy from the limited bandwidth of noise source.
Internally it makes intensive use of an entropy buffer (random pool)
that allows to overcome short-term disturbance and interference effects
on the device without any tradeoff in random data quality. Yet, in case
of heavy disturbance, the device may even interrupt the serial data
transmission by means of RTS/CTS handshake.
- Noise source. This newly designed source of entropy utilizes
nonlinearities and chaotic noise effects in a standard comparator IC.
In particular, there is no zener diode arount and thus no higher
voltage supply needed to run this circuit. As with the XR232, a second
amplifier performs quantization that delivers "digital noise" to be
processed in a pure digital way by the µC.
From a technical point of view, XR232USB looks very different to the classic
XR232. Yet, the continuity is, that we also got clearly defined functional
blocks in XR232USB, which enables to keep good transparency with this
more sophisticated device as well.
Present circuit goes with an SSOP chip (FT232RL) and some miniaturized
but standard components around. This "hybrid approach" with small
PCB of less than 25 x 50 mm already makes for a stick.
When size and cost doesn't matter, building a
deluxe-version in a solid metal case may be worth considering.
This project is and will ever be open source. All materials
needed for making the XR232USB-device and its current firmware can be found
in the download package and have been set under
GPL. I've also written a simple console tool,
that is suitable for classic XR232 and XR232USB and provides some
elementary testing functions for the random source, further
features may be integrated in the future.
Up | Index
The project makes use of the mighty FT232RL
from FTDI in its standard
configuration as a USB-COM-converter. Since those FT232s have been on
the market for several years now, and myself having adopted FT232 chips
in several applications since 2008, confidence in this technology
seems to be justified from my point of view. (In fact, there's not much
other hardware and driver solutions around with that reliability
Basic functionality of the FT232: One end connects with USB while the
other end provides all (8) RS232-lines that we also find at the 9p-DSUB
RS232 connector, but with 5-volts logic levels. These may be directly interfaced
to LSTTL, MAX232 or a µC as well. On the part of the PC system, there are
certainly drivers needed to make use of this USB-device. Fortunately FTDI
provides their so called "virtual COM port" drivers (VCP) for free.
For almost any software running on the PC, the virtual serial ports
are as real as any real COM ports are as well :)
FT232 in XR232USB: The FT232-terminals TXD, RXD, RTS and CTS
are connected to portlines of the µC that provides, among
others, real RS232/XR232 protocol funktionality against FT232.
Pros: The FT232RL is one most advanced member of the
FT232-family. FT232RL can operate with nearly no external components.
In particular, there is no external clocksource needed anymore. The
chip has a very small footprint and might be easily integrated
into many designs formerly using MAX232 for RS232-connection. As
mentioned earlier, those FT232xx are pretty reliable piece of
technology on almost any Windows (from W98 up!) and
Linux environments. Current Linux Kernels even support FT232 devices
out of the box, so there is no additional driver modules needed to make
use of FT232-based USB-devices. The affordable pricing
(about 4 Euros now) and its good availability are in fact further
advantages of the FT232-System.
Cons: Is and remains a 'proprietary' solution. There are not much
details on the FT232-core and sourcecodes of the drivers available.
The chip is, without prejudice, a "black box". More than that, users may be rather put
off by the tiny SSOP28-package that will require plenty of SMD expertise
to solder in a non-destructive way... Also the PCB-requirements are comparably high.
No USB fun without USB drivers! Those drivers for the
FT232-Family have always been freely available on the FTDI-Website so far.
Once installed, the driver will recognize every FT232 that has ever
been plugged in to any USB-port within some seconds. Then a
COM-number will be assigned to that FT232, which seems pretty
consistent and independent of the actual USB-port the FT232-device has
been attached to. The allocation of COM-numbers may be changed later
with admin rights in the extended hardware properties dialog.
We are using the
from ATMEL-Corporation in this
project 'cause it's a small but strong AVR providing just the right
number of I/O ports and having other advantageous features making him
fit perfectly for this project.
- Even the standard PDIP-variant of the ATtiny85 has small enough
outline to make some kind of "USB-stick".
- The ATtiny85 doesn't need any external oscillator for clock source
and it can even produce internal 16 megahertz of clock frequency with
good stability. Being programmed in pure machine code (Assembler) will
discharge plenty of arithmetic performance.
- The ATtiny85 offers not less than 512 bytes of internal SRAM,
from which the largest amount may be used for a "random pool".
- The overall power consumption is very low, despite
that high clock rate the controller is running on (only about 5 mA).
- The ATtiny25/45/85 series has been explicitly specified for
"industrial/automotive" field of application - thus promising even
higher reliability than other AVR-ATtinys.
The ports PB3/PB1 are directly connected to FT232-lines
TXD/RXD. This is the controller's RS232-communications port using XR232
protocol (see Firmware-details).
The ports PB0/PB2 are logically coupled with FT232's RTS/CTS.
These handhake lines enable the controller to deliberately stop a
transmission temporarily if disturbance of random noise source was
Input PB4 is fed with "digital noise" coming from the external
electronic noise source. This is a squarewave-shaped high frequency
signal with some hundreds of kilohertz bandwidth and strong random
characteristics. As a matter of fact, we do NOT use the internal ADC
of the microcontroller, because it could not deliver sufficiently
independent randomness at all. Even if we only took the LSB from ADC probes
of an externally injected analog noise, these bits would surely correlate
with some internal processes in the AVR core, making this method inacceptable for
independent random number generation. (ATMEL recommends to mitigate this
effect with a feature called "noise reduction" - but that does not mean anything else
than completely stopping the controller's programme execution for the
duration of every single AD-cycle, thus cracking down all computational
performance of the AVR most of the time, which is no option for this application as well.)
The current solution offers strict separation between the "digital part"
(AVR) and the "analog part" (the comparator noise source and quantization amplifier).
The RESET input of the µC is coupled to the RTS output
on the FT232 with a small capacitor. As soon as the Host
regularly opens a serial port regularly (with hardware handshake) and
has some characters to transmit in the transmit buffer, RTS falls
to 0 volts (Low level, inverted logic compared to RS232/V24 levels).
The capacitor (C10, 10nF) differentiates the falling edge of that signal
and delivers short negative pulse to safely trigger the reset
line of the µC. Since RESET Being a nonmaskable interrupt, the
reset-method will always work, even if the controller's firmware should
seriously crash or hangup. The controller may always be reset just by a
closing and reopen of the serial port, initiated by host software.
The LED is pinned to +5V and, a current-limiting resistor and the
port output PB2 (which also feeds the CTS input at the FT232).
The LED lights up every time the serial port is regularly opened AND the from the
moment, the controller has run through the reset routines and finally acknowledges its
readiness to do serial transactions (CTS activated = pulled LOW).
Should this LED flicker while the serial port was continuously open,
this is an indicator that the noise source has experienced external
RF-disturbance (or severe voltage instability on USB). In this case,
the logic will have already prevented forwarding of possibly corrupted
random data to the PC (see Firmware).
Noise Source (IC3)
A conventional noise generator based on a zener diode cannot be operated
with a voltage lower than 10 volts approximately. However, on USB we will
only get about 5 volts without extra magic...
I have done some quite exhaustive experimentation with voltage doubling,
more exotic components, photodiodes, op-amps, resistive noise and other stuff,
but it did not really succeed. Some concepts were basically working, but
far too instable, too narrow-banded, too sensitive for electromagnetic
interference, or too complex - or all too-gether :-(
Finally I came to elaborate the following circuit based on a quite common
and standard component: the LM393
double analog comparator. My circuit utilizes a strange effect that is
in a regular comparator setup. Because of its small hysteresis and very
factors, if one applies feedback to the negative comparator input, such
comparator will tend to instability and chaotic oscillation. Yet, with
few external components, it IS possible controlling this effect and
enforce stable noise generation with frequencies range up to the cutoff
frequency of the comparator.
Just to mention, the present circuit, which delivers reproducible
results with any breed of LM393, has been optimized by empiric testing
and experimentation with real components in real circuits, rather
than theory and simulation stuff.
Pros: Much entropy for little money! Those LM393 have been
around the electronics world for decades and are still available from
manufacturers in large scale. The proposed noise circuitry works
reliable with operating voltage from 4 V up. The second comparator
system is beneficially used to build the "1-bit-digitizer" and thus
delivers the attached microcontroller with a digital signal. It seems,
that feedback to the first (sensitive) noise generating stage is
negligible in this application. So, this second stage will separate the
microcontroller from the noise system. Since the comparator level for
this buffer stage is not floating but fixed by means of R3/R4, no
tendency for self-oscillation could be observed.
Testing many different series of the LM393 has shown noise spectra up
to 300 kHz.
Current consumption is unter 1 mA.
Cons: There IS sensitivity for RF-interference in the unshielded
circuit assembly. This effect could be demonstrated with household
transmitters, like radio remote controls, GSM 900/1800-MHz mobile
devices, and a 2400-MHz WLAN adaptor, being placed
only few centimeters nearby the comparator circuit. Overall, the
sensitivity for UHF and microwaves seem smaller than classical noise
source in XR232 build of discrete components. As a matter of fact, even
elementary means of electromagnetic shielding will drastically reduce
Similar effects are caused by fluctuation at the USB supply voltage.
In a real-life PC system, we often have to deal with lower-frequency mumbling on
the voltage rails, that is caused by peak loads of CPU, HDDs, CD/DVD-drives or
graphic cards. Those tiny elcaps on the mainboard won't remove
the deepest "bass" notes of that disturbance.
Fortunately our comparator noise source does not draw much current (less than 1mA), so we
are fine with filtering the 5 volts with an simple R-C filter (R7=470 ohms / C9=47 µF).
Just to mention, all parameters of the circuit are kept well within the limit
values indicated in the datasheet. Half a dozen of LM393s have been tested successfully in this
circuit, so I tend to be optimistic that the noise generator will work with most
comparators of this type exactly the way it should.
Directly soldered onto the board, the PDIP version of ATtiny85 will
need less than 4 mm of headroom, which is already compact enough for
the intended "XR232USB-Stick".
Fusebit configuration and flashing of the µC is still
possible "in system", by means of the 6-pin-SIL connector, named X2
here (see picture).
In the development of the circuit, port assignments of the ATtiny85
have been chosen in such way, that ISP
access will not collide with output terminals of the FT232 or the
controller, as long as the RS232/FT232
port is surely "closed".
Since there is no "official" connection scheme for single-line ISP/SPI
connectors, the sequence of signal lines on X2 has been setup for pure
practical reasons (layout). See following diagram!
2X5P (ATMEL-ISP) to XR232USB (6P SIL)
Note: As soon as the ATtiny85 contains a suitable bootloader, we would not necessarily need X2 for flashing a new firmware.
Of course, the firmware for the ATtiny85 has been written in pure assembler language.
It's all about performance and transparency. For those who do not like even well
commented assembly source, the following remarks and explanations may be intelligible enough.
Collecting random data
Being a pure software implementation, the sampling method shall be
customized for the respective source of entropy. In here, we got an
electronic noise as an entropy source of limited bandwidth.
This analog noise is then converted by second comparator into
a squarewave sognal of variable pulse length. All entropy of this
"digital noise" is being vested in the time domain. Microcontroller's ports
can read such signal without any further information loss.
My proposed method of bitsampling is to continuously take probes of that
digital noise with the highest oversampling factor possible.
As long as the digtal level remains unchanged, a fast binary counter is
free running and thereby measuring the actual duration of the signal's state.
Only with the next level change, the LSB of this counter will be taken
to provide exactly one new random bit.
This method has two benefits: It offers pretty good balancing of
random data and it is quite insensitive against predominant
In contrast to simple S&H-schemes, no aliasing products occur, even if
the sampling clock reaches or exceeds upper frequency boundaries of the noise. (Yet, the overall
entropy of the gained random data would degrade.)
Overall efficiency is similar to the Von Neumann method. Despite the digitized noise
at the second comparator's output will most likely have a remaining bias of some
percent, the first computational steps of bitsampling make sure that the bits
harvested from the noise source will only have a few 0.01 percent.
In a second step every 8 random bits are combined to form a byte, which is then
XORed with older byte from the random pool. Doing so, all bytes in the
random pool are repeatedly refreshed with an average processing speed of
several 100 kbits.
Since the procedure delivers a numerical value that indicates pulselength as a by-product,
it is easy to detect irregularly long periods (= low frequency components) in the
source signal. This could indicate disturbance/interference effects on the electronic
circuitry, in such case there may be 'preventive/compensative measures' necessary
(resort to random pool data or even interrupt the data transfer).
The bitsampling routine of a current firmware can check momentary state of the noise
signal more than 1 million times per second. Values of the pulswidth counter
ranged between 2...14 units (forwarded in a special debugging setup).
This would be equivalent to a noise spectrum with frequency components of roughly 38...220 kHz.
(When digital noise was directed to a frequency counter, we get average frequency of 140 kHz,
which leads to the estimate that this kind of entropy source may deliver about
280 kBit/s (= 35 kByte/s) of random data at maximum.)
The internal random pool of nearly 500 bytes (= 4000 bits) is thus refreshed
about 70 times per second. This value has also been counterchecked by further
measures/testing. Of course, these values will slightly change with any programming modification,
but it's good to know the dimensions. Conclusively, it should be no problem
to fetch random data from the device even with an average rate of 230.400 bps.
Differences between XR232 and XR232USB:
With the classical XR232 an oversampling of the noise source is not
recommended (and already limited by the reduced bandwidth of the optocouplers).
In classical XR232 the digitized noise is only balanced by frequency divider,
then sampled with regenerated TXD clock pattern, added with
start/stopbits and then directly sent to RXD. In classic XR232 the
random data delivered will always reflect some kind of snapshot from the momentary
state of the noise source.
The microcontroller in XR232USB does pretty more processing with the
noise. First the µC samples and processes random data bits in a continuous way to
permanently refresh some random pool. This pool is not only forming a short-time
buffer, it accumulates and preserves entropy, even if there is no random
data requested by the host. Thus, in XR232USB, the operations of reading random
and actually sampling that data from the noise source, are de-coupled from a timing
Read out of random data
According to XR232 protocol the host requests random data bytes by
sending a special or "magic character" to the serial port. This is the "U", ASCII
code 85, or 1010101010 in binary notation (start
and stopbits highlighted). The device answers with exactly one byte of random per magic character received.
That hard-wired logic of XR232 worked in realtime. Yet, any microcontroller may
also be fast enough to detect TXD-level changes and respond with serial
characters up to a certain baudrate. (Effective programming in machine language provided...)
One clear advantage of the µC is the option to make use of internal SRAM
to establish a kind of Random-Pool. This allows to buffer serial access and thus largely de-couple the process
of random data sampling from random data delivery.
To achieve this, the bitsampling routine must run with
highest priority and without the risk of being interrupted by interrupts, so
there is no interrupts at all. All TXD/RXD-related operations are in fact
done by the 'polling' method and are thus only side jobs of the main programme,
whose main task is to sample and process random data bits with highest processing
speed achievable. This works fine up to 230400 and even higher baudrates with
tolerable timing jitter on the serial bits. (Which we owe the fact that timing-errors
cannot accumulate in XR232 protocol!)
BTW, there's certainly separate address-counters for reads and writes into the random pool.
XR232USB access timing (do not scale from this drawing...)
tRES = Hardware-Reset, only
tdis1 = short disturbance < 20 ms
(completely bufferd thru Random-Pool)
tdis2 = long disturbance > 20 ms (cause
CTS-interruption and launches Restart)
tR1 = detection time for a "long" disturbance,
about 20 ms
tR2 = deadtime (time to wait for noise source to
tR3 = regeneration time (refreshing Random-Pool)
Hardware reset may be triggered by powering up the device
(power-up/brownout reset) or by pulling the µC's RESET-line to Low-level
(external RESET). As already mentioned in the
Hardware section, controller's
RESET is also triggered by the falling edge of RTS coming from FT232.
RTS goes Low after the interface has just been opened by the host
and first characters are ready to be sent in the transmit buffer. The device
shall react by pulling down CTS (within the specified timeout-periods)
as soon as the device is ready to receive any characters.
(Seems that RTS-CTS flow control is more flexible compared to DTR-DSR,
which does not allow both parties to temporarily interrupt transmissions.)
Reset: Directly after Power-on or Hardware Reset induced by RTS,
the firmware keeps CTS line deactivated. This is to signalize the PC
that the device is not ready yet. First of all the firmware will
re-initialize the registers and ports and then refresh the random pool
in SRAM. To ensure that corrupted random data remains in the pool but
also to benefit from older entropy being "recycled", the whole random
pool is rotated some thousands of times. After about 1/10 of second,
firmware then activates CTS
tell host that it is now for delivery of random data.
If there has been severe disturbance whilst in transmit mode,
uncorrupted random data from the pool would rapidly exhaust and the
firmware cannot deliver fresh random data so far. Thus, the firmware
must deactivate CTS and sit the disturbance out. If disturbance has
passed, the firmware will jump into the Reset procedure, do the big
refresh of random pool and then re-activate CTS to resume transmission.
Handling of interference
The random number generator does its best to guarantee that supplied
random data was not corrupted by external disturbance.
If however serious interference occured, the software should be alarmed.
Due to its electronic working principle, the noise source has
sensitivity for RF-interference and AF-fluctuations on its supply
voltage. Both effects can be coped with by several physical and
electronic measures, but in a µC-based appliance, it should also be
monitored and, of course, compensated as required.
The noise source normally delivers bandwidth-limited noise in a
frequency range of some tens up to hundreds kHz. Disturbance of this
circuit will cause lower frequencies to occur, in extreme, static
output levels. These effects can be safely detected by the firmware.
The random bitsampling routine would not do further random data writes
as long as the noise source is "down". This feature protects the random
pool from catching "spurious patterns" that may be induced by
subliminal interference of the noise source. To conclude, any shorter
interference will only cause short interruption of the process of
random bit harvesting, but this is completely uncritical as long as the
pool gets refreshed fast enough to recover.
However, some disturbance of longer duration, say, some 1/100 seconds,
may lead to performance problems, if random data is continuously
requested with high baudrates. Only trustworthy method to cope with this:
Stop delivery of random data. Wait untilnoise source has safely recovered.
Refresh the pool thoroughly.
The second disturbance depicted in the diagram lasts approx. 5 ms
(tdis2). After 2 ms (tR1) the firmware has recognized a longer
interruption of noise. Now CTS must be deactivated to prevent reading
of degraded random data. Now the program waits until the noise-source
has recovered (tR2). After this "dead time" of further 3 ms (tR2),
wideband noise returned, so the firmware launches an extended reset
(coldstart) and refresh the pool thoroughly. Finally it activates CTS
and transmission goes on!
Effects at host side:
If the XR232-software running on the host PC has been configured
for a generous RTS-CTS-timeout, there might be interference on the
noise source of random generator even seconds lasting, without an
interface error being detected. This means, there is no need to even
reinitialize the COM-port for continuation of the data transfer! This
option seems meaningful for unsupervised generation of large random
files, or with applications, where fast recovery from possible
disturbance has the highest priority.
If on the host PC a stricter timeout for RTS-CTS was applied, longer
disturbance and CTS-deactivation will surely exceed the timeout and
lead to an interface error. The software will have to close the
COM-port and reinitialize it after some latency time.
Firmware measures approximate baudrate by the leading
startbits of the magic characters sent by the host. If incoming characters' baudrate is under approx. 2400 bps,
the firmware immediately switches to an "identification mode".
In this mode the device will respond with an ASCII-string identifying
the device and build date of the firmware, one character of
the string in turn for every magic character issued by the host and
repeated forever, als long as the host sends its magic characters.
This enables XR232-software to differentiate betweeen real/classic XR232
and XR232USB devices and their firmware version. Software may then use higher transmission
with XR232USB as with classic XR232. The identification string is located in
the flash area by the firmware code.
Note, that the identification mode must be stopped by closing the serial port before regular random data transfer will resume.
Finally, a Bootloader matching all technical and ideological requirements of this
project, is available. Refer to my project TinySafeBoot !
Up | Index
The commandline tool "XR232NT" is a 32-bit executable,
available for win32 and linux systems. It has been written
under that marvellous and platform-independent FreeBASIC.
The software makes consequent use of block transmission methods, favourable for both,
XR232 and XR232USB (genuine and virtual serial port) implementations under recent OS.
Robust error handling allows unattended operation (e.g. to produce large random files).
New reasonable features and bugfixes are likely to show up in future versions.
Features of XR232NT:
- autodetection of XR232/XR232USB devices
- testing general functionality of XR232/XR232USB
- precision check of absolute balancing (digital sum value)
- graphical testing (bitmap, byte frequencies)
- generate random files of N bytes, kilobytes, megabytes or gigabytes with additional balancing options
- read-out of XR232USB-identifier
- uses COM1 - COM255 under Windows
- Linux-Version: same functionalities, use of /dev/ttySx or /dev/ttyUSBx
!!! Finally we have a workaround for a FT232/FreeBasic related issue with "sticky-baudrates" !!!
On certain requests, i offer diverted XR232-specific Library (.dll / .so) now.
This will ultimately enable programmers to make use of XR232/XR232USB without being bothered by specific serial port stuff. Please have a look at it, since it is still 'beta' and i will appreciate any constructive feedback.
Up | Index
You will find a proven PCB layout for XR232USB hardware version 1.0 in
the zipped package as usual in a high resolution bitmap graphics
format. (I neither use vector graphics nor proprietary layout software,
so please refrain from asking!)
While current version with mixed component already makes a nice "stick", i would maintain this variant for the time being.
Requirements of this PCB reproduction and soldering are comparably high only because of the one SSOP chip.
General recommendation: First solder FT232RL with a minimum of (leaded)
tin, then the minimum of external wiring needed for connecting with USB.
Check for proper recognition of FT232 chip and assignment of a new COM-
resp. /dev/ttyUSB port, few seconds after plugging into any USB port.
Additional testing may include a temporary connection soldered between TXD-RXD and
RTS-CTS, which would basically allow some loopback testing by means of
a terminal programme. After successfull completion of these tests, you
can do the remaining components much much more relaxed...
However, this is definitely no project for beginners, and you must either
be very good in improvisation or you should have some SMD-specific tools at hand!
The package includes a PDF worksheet with bill of materials, site
plan and other circuit documentation.
(Well, actually it's light metal...)
Picture below shows a slightly modified
XR232USB-PCB in die-cast aluminium housing.
That's not only giving (justified) premium look-and-feel, it actually
provides excellent mechanical and electromagnetic protection against
RF-Flooding and other possible disturbance.
Up | Index
|Raw random data
visualized in bitmap
|Testing digital sum value (block/overall)
data and byte-valencies
|Picture shows the accumulated
IMPORTANT NOTE: These integrated checks are merely 'illustrative' and should only prove basic functionality of the XR232/XR232USB hardware. It is of course recommended to run any sophisticated tests (e.g. DIEHARD) over a large amount of random data sampled from the TRNG under realistic conditions before using such device for crypto or other critical application.
Up | Index
Up | Index
Revision history: 09/2011, 07/2012, 11/2012, 07/2013, 01/2014, 07/2014, 04/2015