lighthouse-4 deck doesn't work properly

[josevtecc]

Hi everyone,

We're trying to use the Lighthouse deck from Bitcraze to obtain the position of the deck using two SteamVR Base Station 2.0 lighthouses. We created the route '/bitcraze/' where we installed:

• 'icestorm', 'nextpn'r, 'yosys,' and 'arachne-pnr' in independent folders.
• We also did a git pull of 'lighthouse-fpga' and 'lighthouse-bootloader'.

On lighthouse-bootloader, if we run 'make prog', an error occurs:

I didn’t understand “(vendor_id 0x0403, device_id 0x6010…)". When we check with 'lsusb', we see:

Looking at the code, we assume that the error message is programmed and it never actually tries to read the 0x6010 device ID. Also, 'make prog' doesn’t work, but we can boot the FPGA as shown here:

The red LED turns off, so booting is performed. Why doesn’t 'make prog' work?

Now, on lighthouse-fpga, if we run 'make' (before bootloading the FPGA), we get a lot of information, but an error occurs:

So, we boot the FPGA, and repeat the 'make':

The same error occurs. Do we need to place the lighthouses at a specific distance? Should they be turned on or off?

Additionally, we tried 'print_frame.py' but no progress is made beyond “waiting for sync…”

We are using an FTDI cable chip USB to UART (ref. TTL-232RG-VSW5V-WE), where we connect:

• Red 5V to Vcom on the lighthouse-deck
• Black GND to GND on the lighthouse-deck
• Yellow Rx to Tx on the lighthouse-deck
• Orange Tx through an 8.5K ohm resistor divider to Rx on the lighthouse-deck

Any suggestions would be appreciated. Thank you very much.

[ataffanel]

Hi,

If all you want is to use the deck, you do not need to recompile the FPGA bitstream, you can use the releases bitstreams and use the bootloader. Programming the FPGA via SPI requires populating jumpers on the board, this is not needed as long as you can access the bootloader.

You can find the latest bitstream in the release page: https://github.com/bitcraze/lighthouse-fpga/releases. You can write it using the bootloader script and then there should be a data stream comming on the serial port.

Your cabling seems correct, it is very good that you put a voltage divider to protect the board.

[ataffanel]

Can you check that you are getting bytes from the UART using a terminal or a program? When working properly the design will send one data packet every 500ms as synchronization even when no pulse are detected and it should send one data packet per pulse so switching ON a base-state should make it send a lot of bytes over the UART.

[josevtecc]

We have tested several methods (minicom, picocom, screen) to monitor the UART output, but we don't see the expected data packets being sent every 500ms for synchronization. However, we do observe various symbols appearing in the terminal when we make some movements with the deck, although they are illegible. This suggests that the communication might not be properly configured.

We have tried adjusting the baud rate and parity settings, but there were no noticeable differences in the output.

[ataffanel]

The data sent on the UART are binary data, so they will not be clear text on a terminal. Though the fact that you see data is a good sign, it means that if you use one of the script on the UART at 115KBaud, you should get pulse information.

[josevtecc]

That's an example of the output from "picocom -b 115200 /dev/ttyUSB0"

Then, when we test the code "printframe.py" the terminal shows always "Waiting for sync ..."

[knmcguire]

@josevtecc Arnaud is now out of office but we will notify him on your update next week. Sorry for the delay!