Thank you for sharing

[tpy37]

Hi, it's Tatsuki from Tsukbua Uni. I stumbled upon few hoops whilest recreating the hardware, and I thought it might be worth sharing. If I am doing something terribly wrong ... please do let me know!

Controller Board

1. The BOM does not seem to be defined for JP1 and JP2. Looking at the circuit diagram, it's seems to be jump. I assume the two conectors simply neeed to be bridged (which I did so by soldering them together for now..)
2. B6 component specified in the BOM seems to be too big. Maybe a parts with smaller footsize might be correct?
3. PF3 wasn't defined, but I assume it's also a fuse.
4. Component J5, J6, J7 seems to be missing, but again by inspecting the circuit diagram, I assume it's for a fan so I skipepd this part for now.
5. The small footprint of USB, 5V, REG seems to be some kind of two way switch which wasn't mentioned in the BOM, but I decided to bridge it by solder. Only between the REG and 5V. It seems like you can chose between FPGA board powered by USB or regulator.
6. Master / Slave pull down seems undefined at the moment. I am not sure if to bridge it or not bridge it for master selection.
7. J8 is also seems to be introduced newly to the board, and I haven't figured out yet. From what I figured, it is an option to get powered by different board? From the circuit board, it seems JP2 selects whether it is externally sourced or not.

Serial communicaiton The board uses FT232H, and my computer did not automatically detect it and it apepared as USB serial converter. I referred to this site to fix it. https://bigdanzblog.wordpress.com/2021/05/14/installing-adafruit-ft232h-breakout-of-the-ft232h-usb-to-serial-converter/

I am still going through the electronics myself, but I hope this note will be helpful.... And lastly but not least, thank you to team at UCL for sharing the board :)

[cabezabuque]

Hi Tatsuki! First of all... welcome to the forums!! It is really exciting to learn others are replicating the board, and I am sure you guys will make great things with it!! I will need to review the files and BOM in the repository. We have gone through several versions of the hardware before we reached this point, and from what you say, we must have made some mistake when collating the files. As per the fans... yes, we played with these at some point and those pins are still there in case we want to add them again. They are not strictly necessary (we do not use them).

As per the Master/Slave jumper, one of the boards MUST be working as a master (no jumper), and the others as a slave (jumper). The master will share its real time clock so that all boards work under the same 40KHz signal.

As per the FT232H, I think I know what the issue is there. You need to pull out the ID of your chip, which you can do easily from the "Device Manager". With the boards connected, find your "Ports (COM&LPT)"

Ignore the numbers that this is showing (COM13 and 14), as these might change if you connect the boards to another PC. Right click on one of the devices, select "Properties" and go to the "Events" tab. Over there, you need to look at the "Information" textbox, and the code that you get between the last '+' and the 'A' (this is '18' in my case).

In your case, this might be a larger code (8 characters, including letters and numbers). When we manufacture our boards, we use FTProg to change that code to a number that identifies our board, just to make thing easier.

Get the codes for each of your boards (and make sure you know which one is which!). The next thing that you need to do is to write this code into the ".pat" file of each board. You can find these files in the "OpenMPD_Client" folder (if you use the Unity client) or in "OpenMPD_Libs\libraries\bin\x64" (if you use the C++ one). In either case, open the .pat file of your board and look at the first line. This is the case for "board7.pat" (assuming I decided to name my board "Board 7"). When I open it, I see:

I would go ahead and change that code by the code I read from the device manager. In your case (if you have 8 characters) it could look like this:

A final note... you also have access to all the code required to compile and debug other parts of the software, such as the drivers and the solvers (GS-PAT, IBP, Naive). Take a look at the landing page, each of them is a separate repository.

I hope this helps!

Diego

[tpy37]

Thank you very much Diego, and I am sorry for the misunderstanding regarding the hardware drivers. I did find them in the OpenMPD Drivers Github repositroy.

Thank you for your suggestion to change the serial ID on FT_PROG. I am not expert in this.. but it might be mandatory step to change the serial ID using FT_PROG (downloadable from https://ftdichip.com/utilities/), as the default serial ID was like this for me:

Having changed the serial ID, I was able to connect to the board via Unity! I have new problem in Unity now (when I press play, it freezes completely)... but step by step..

I made a short code in Python to unit-check if serial id is correctly identified or not: pip install ftd2xx

import ftd2xx

def open_ftdi_device(serial_number):
    """
    Opens an FTDI device using its serial number and returns the handle.

    Parameters:
        serial_number (str): The serial number of the FTDI device.

    Returns:
        handle (ftd2xx.FTD2XX): The handle to the FTDI device, or None if the operation fails.
    """
    try:
        handle = ftd2xx.openEx(serial_number.encode(), flags=ftd2xx.defines.OPEN_BY_SERIAL_NUMBER, update=False)
        return handle
    except ftd2xx.DeviceError as e:
        print(f"Could not open USB port: {str(e)}")
        return None

# Example usage
serial_number = '100'  # Replace with your actual device serial number
ft_handle = open_ftdi_device(serial_number)

if ft_handle is not None:
    print("Device opened successfully!")
    # Perform operations with the device here
    ft_handle.close()

Hope it helps people like me (novice C++ programmers) to unit-test whether if serial com is correctly setup.

[cabezabuque]

Could you copy the output that you get from the Unity console? Make sure you tick the "verbose Mode" in "_LevitatorOrigin->OpenMPDPresentationManager", as that gives more info. A few quick things:

• Make sure the boards are powered: Connect the boards to your PC with the USB, and then connect the power adaptors. The boards consume packages in sync, but the FPGA needs to be powered for that to happen. Without the FPGA consuming packages, the PC will continue to push packages into the queue, the queue will get full and the sender (PC) will get stuck when it tries to send the next package.
• Use the C++ client for initial stages: Unity is a bit nasty, and you can only see the C# code, but nothing inside the C++ DLLs (which are the heart of OpenMPD. On the other hand, the C++ client allows you to debug inside each of the DLLs, which is great to see what is going on. Once you are all set-up, Unity might be easier to use, but at this point C++ will allow you to get more information. Hope that helps. If it doesn't, send the console output and we can look into this.

[tpy37]

Dear Diego,

Thank you very much for the support. I am still having issue that I cannot change the phase of PAT after initiating the communication with the FPGA board. For example, if I try exampleHapticsSTM, it does not allow me to change the settings, and cmd freezes. I was wondering how I could make sure that the FPGA board is consuming the packages. In Sonic Surface, one of the LED on the FPGA board blinks when it receives the package, and I was wondering if there is similar features in the OpenMPD. I checked each connections of the board, and I am not sure what else to check to get it communicating.

Best Tatsuki

[cabezabuque]

Hi! The FPGA has a buffer of up to 32 packages, which it applies at a fixed rate (assuming you use a FPS_Divider of 4, it applies one update every 0.1ms). This way, if the client's rate changes (not exactly sending 10k packages per second, as it is not a real time OS), the buffer will avoid timing issues. The state of this buffer is shown by the 4 red LEDs on top of the board (4 red=full, no red=empty). Now, if you do not power the PAT while you send the packages, the FPGA cannot consume these packages. The buffer gets full (4 red LEDs), then the queue in the USB communication gets full and the next time the sender (your PC) tried to push a new update, it gets locked. So chances are you only need to make sure your PAT is powered when you are sending packages. Let me know if that works. Diego

On Tue, 7 Nov 2023, 09:46 Tatsuki Fushimi, @.***> wrote:

Dear Diego,

Thank you very much for the support. I am still having issue that I cannot change the phase of PAT after initiating the communication with the FPGA board. For example, if I try exampleHapticsSTM, it does not allow me to change the settings, and cmd freezes. I was wondering how I could make sure that the FPGA board is consuming the packages. In Sonic Surface, one of the LED on the FPGA board blinks when it receives the package, and I was wondering if there is similar features in the OpenMPD. I checked each connections of the board, and I am not sure what else to check to get it communicating.

Best Tatsuki

— Reply to this email directly, view it on GitHub https://github.com/RMResearch/OpenMPD_Hardware/issues/1#issuecomment-1798150423, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEACJPPO7BT4SI4UEQKNTTYDH7NRAVCNFSM6AAAAAA5Q2TZNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGE2TANBSGM . You are receiving this because you commented.Message ID: @.***>

[tpy37]

Dear Diego,

Thank you for your continued support, and I am sorry to keep bugging you! As per your instruction, I fire up the board in the following sequence;

1. Connect USB-C Cable. (Only turns on the FT232H).
2. Connect the DC Jack, (Powers on the FPGA board).
3. Open executable of exampleHapticsSTM. (The CMD does not respond to inputs).

This is the LED states of the board, after step 2, and remains unchanged. From your explanation, it looks like the board is empty, and is not receiving the buffers at all from the FT232H. Since the FT232H is recognized on the device manager, I think there is something between the board and the FT232H... I checekd the connectivity between the FT232H pins and the FPGA board pins, but I haven't found any issue so far...

[cabezabuque]

Hi Tatsuki! I was just checking your board against the ones I have around, and it seems that everything is correctly populated in the control board. We should try and test the connection between the FPGA and the FT232H, but I need to think of an easy way to do this. I'll check the connection pinout and see how we can do this easily...

[cabezabuque]

Hi! I have been checking how boards behave when they are just connected to power, and I realized the LEDs do not turn on until you start sending messages (USB connected, and OpenMPD sends the first message). So... it is possible that the behaviour you are observing in the LEDs is totally normal, and the board is working... It would be great to get a video of how your board behaves when you first turn it on. That is, the board is not connected to power, and you plug it. Do you reckon you could do that? Diego

[cabezabuque]

Hi @tpy37 ! Any luck testing the step above? Diego

[tpy37]

Hi Diego,

I am sorry! I was away this week, but I will have a go tomorrow, and update you with the information above!

Best regards, Tatsuki

[LordMelman]

Hello! Not Tatsuki, but I believe I am currently experiencing their exact same setup situation. I can establish a connection between OpenMPD on my PC and the FT232H, but there doesn't seem to be any indication that the commands are consumed by the FPGA as the LEDs don't flash and the transducers don't seem to change.

I have noticed different states depending on the order-of-operations I follow at startup:

• If the USB is connected when I power on, the amp draw is very low (0.09A). There are no noticeable flashes on the FPGA LEDs.
• If the USB is NOT connected when I power on, the amp draw is much higher (~0.7 A). The FPGA LEDs flash in a relatively consistent sequence.

I have attached videos of startup as you requested. I've included 1 video of it starting w USB connected and 2 angles of it starting with USB disconnected. Does this seem consistent with standard behavior?

https://github.com/RMResearch/OpenMPD_Hardware/assets/65552535/cb828b56-a40e-44e6-898d-5a2863452972

https://github.com/RMResearch/OpenMPD_Hardware/assets/65552535/ff0dcafc-509a-41fe-8b84-a959fccb45c6

https://github.com/RMResearch/OpenMPD_Hardware/assets/65552535/f7c2e986-e5b1-4299-9580-410458c85ea8

[LordMelman]

I have been testing the connection with the _6.simpleGSPATCppAsierInhoV2 example found in the OpenMPD_Solvers repo. It has been slightly modified to be single board with our board ID, 5. When I view the communications via WireShark, I do see that TX communication is made at startup (presumably with the initial position) and each time I make a position change with w,a,s,d. The board does not seem to update. No LEDs or apparent change in power draw, phases, etc. FWIW the c++ project makes the updates VERY slowly when the board is connected, A couple minutes can pass between key press and confirmation message + TX seen in Wireshark

The device address changed between runs (in this snip it was 34) but behavior seemed consistent

[LordMelman]

My issue has been resolved! I am now able to directly control the board with the C++ examples (still not Unity but progress!)

TLDR: Need to make sure both the FPGA core and FPGA programmer circuit have been flashed properly. For the boards here, that meant flashing them separately.

Long Answer: The CoreEP4CE10 involves a FPGA programmer circuit (EPCS16). This circuit element can be abstracted away as a Flash memory module (meaning the stored values are persistent even with power off). In the Quartus programming view, the EPCS16 can be viewed as connected to the FPGA:

The EPCS16 can be individually programmed through the .jic (JTAG Indirect Configuration) file interface to store code for “startup”. On the other hand, the FPGA core requires a .sof (SRAM Object File) which is compiled as part of the ‘Assembler’ step of the Compile Process this .sof isn’t persistent across power resets thus relying on the .jic to reprogram the FPGA on startup. However, the JTAG sometimes does not properly flash to both (says “Failed” in the Upload bar). In this case, you may need to upload the two configs separately.

Starting with the .sof file, select only the .sof file’s “Program/Configure checkbox” and ignore the .jic file. The dropdown should now look like the following when you press ‘Start’:

Once this step is completed, click “Add File” in the menu, Select the corresponding .jic file. Once this is updated in the dropdown, Delete the .sof line in the dropdown (Click + ‘Del’). Then, select the Program/Configure for the new row with the .jic file and allow the empty row to automatically populate. Press ‘start’

Finally we need to overwrite this Factory default image with the correct .sof. We can double click the requisite line to overwrite the Factory Default by selecting the correct .sof. Also the new empty field can be repopulated with the correct .jic. The final ‘Start’ press should look like the following:

The board should now be properly flashed and ready to receive control input!

EDIT/UPDATE: Unity now works as well! It consumes pat files from a separate repo than the c++ examples. I had updated a pat file for the C++ and just had to replicate those changes for Unity.

[cabezabuque]

That is great! I had never had any issues with Quartus Prime (I use version 20.1), but it is good to come up with these things (well... it will be good for others coming after). Also, I just realized we do not cover the step of programming the FPGA in the document explaining how to replicate it. Maybe we should create a new section to cover that step. Anyways, thanks a lot for sharing, and real happy to hear that there is someone else out there messing with OpenMPD. The fun part of your journey lies right ahead of you!! Cheers! Diego