Mode-S Beast:Hardware Handshake Set-Up
There is an option of using the RTS/CTS hardware handshake between the interface device (mostly USB) and the FPGA. I strongly recommend this in case that you live in a high traffic area, or are getting more than 300 frames/sec indicated on Planeplotter's speed meter. While the common understanding of HW handshake is such as that the PC signals a busy state towards the serial device, this is different here. The FT232R that is used as serial interface device has an internal buffer for the data that has to be sent to the PC. In case that the PC does not serve the USB often enough, this buffer might become full. Therefore the RTS handshake signal is used to signal the conguestion to the FPGA.
BUT this is only done if the HW handshake is enabled on the PC and not independently! In such a case the larger FIFO buffer (512 frames in 1 CH / 2 CH devices, 256 frames in 4 CH devices) in the FPGA buffers data until the interface is again served by the PC. (Technically speaking, it might have been better if the FT232R developers would have enabled this option in the FT232R's internal EEPROM).
Since I will send the devices with USB RTS handshake configured through the solder jumpers, all you have to do is to set DIP#8 to ON (opposite side of the LEDs).
There is a red control LED on the PCB close to DIP#10 that is actually driven by the FPGA as soon as its output is blocked by an inactive RTS signal. So you can clearly see if you don't get messages just because the RTS handshake is active. There are some videos on Youtube showing the behaviour of the red LED in different cases:
Video will be added later
This video shows the behaviour if the RTS handshake is enabled, but the PC software is anyway still not able to handle all data transfer, for example with my 600MHz single core laptop. The red LED is on for a significant time. Planeplotter indicates around 1000 frames per second at this time.
Again with the same data rate, and still the 600 MHz laptop, but only decoding DF-11 and DF-17/18 frames. You recognize that the red LED is on for far less time than before.
Here you can see the same data rate but the COM port beeing served from a dual core 2 GHz PC. The red LED is on for just a few short moments, and even then the blue LED still flashes, which means that these short moments are still bridged using the FPGA's internal FIFO
Video will be added later
The blue "FRAME" led only flashes if the FIFO is still able to receive data. So if the RTS is active for longer than the 256/512 frames are not completly filled, the blue LED will also stop flashing.
For those who want to experiment further, the situation can be improved as well when using COM0COM driver and inserting HUB4COM between the real serial device and the a virtual serial pair that goes into Planeplotter. Even better you can use my CRC driver, which is proven to have the best port performance of all.