USB Control of Procyon Documentation?

[bmookerji]

Hi!

I have a Procyon and would like to control the Ganzframes in realtime using Python. The only library I've found on the Internet is this:

https://github.com/bloff/pyThoughtstream

Does the Procyon use the same interfacing as Thoughtstream? I don't need to do anything with audio, just control over RGB channels with the Ganzframes.

Any resources in terms of serial/USB interfacing with the Procyon and control of the Ganzframes via serial/USB would be greatly appreciated.

Thanks!

[Andy]

Hello and Welcome!

The Procyon uses a completely different protocol from the TS. The TS is quite simple in comparison.
Several have tried to do external control of the Procyon, but found it too onerous. Neuroasis got the furthest, but he has vanished, unfortunately.

[jelwell]

I've started going down this path. I kind of have it working. I can send messages using Python to the Procyon and the lights come on correctly. The part I'm struggling with now is getting the timing working properly.

Here is what I did:
I'm using Wireshark to CAPTURE the USB commands that Procyon AVS outputs to the device.
Then I use usbrply to convert the captured pcap file into python code.
Then I replay the captured commands back the Procyon and the lights on the Ganzframes come on.

Now the tricky part. usbrply doesn't (yet) support sending the messages to the USB device using the timing information captured from Wireshark.

I don't know if Procyon AVS is timing when to send messages to the Procyon USB device or if it's READING from the Procyon repeatedly after a write to figure out if it's ready for the next write. The capture does have 178 times more read commands than write commands. Which is pretty surprising given that the Procyon has no input systems so the data the PC pulls off of seems likely to be just checks to see if it's done with a segment.

I updated the readme on usbrply ( https://github.com/JohnDMcMaster/usb...s-installation ). Check out "Windows installation" and the "Sample workflows" section.

Capturing is straight forward. Once you do that you use usbrply to convert the capture to python code. But you need to switch the USB driver to WinUSB. Follow the directions in "Windows installation" using Zadig. When you want to go BACK to running "Procyon AVS" you will need to reinstall the CP210x Windows Driver.

I have multiple sessions so I captured the short USB commands that "Procyon AVS" uses when you select the COM port and open the COM port. Then I run the python script corresponding to the session I captured.

For now I manually inserted a python call to time.sleep inside of my outputted python file's bulkWrite and controlWrite functions. I just guessed at how long to wait based on how many Write commands I counted in the file and the number of seconds the Session is supposed to run. I'm working with the dev of usbrply to see if timing information can be consumed (I might need to do the work myself) but for now I'm playing with the time.sleep to see if there is some secret on how long the code should wait before (presumably) sending the next segment.

But I'm wondering if I'm trying to hard. The sessions are loaded onto my Procyon already. Surely there is a simple command that can start a numbered session? Or a mode in one of the Procyon tools that can trigger the Procyon to start a numbered session via the USB cable.

[Andy]

The Procyon's communication is RS-232 (often called a COM Port) style. The USB connection is simply a USB to RS-232 conversion.

I found the attached documents. Maybe it will help!

FYI, the "White" color was never implemented, but was still referred to in the attached documentation.

[Andy]

Was any of this helpful?

[jelwell]

Was any of this helpful?

It works. Here is some python code that will start a session.
to use you need install the pyserial requirement.

pip3 install pyserial

I tested this on Windows. You can get your COM port from Device Manager. Or from Procyon AVS...
I can't recall ever writing to a serial port so go easy on me. Happy to receive constructive feedback.

import serial
import struct

port =serial.Serial(
    "COM4",
    baudrate=19200,
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS,
    writeTimeout = 0,
    timeout = 10,
    rtscts=False,
    dsrdtr=False,
    xonxoff=False)

#this will output the checksum hi and low bits.
#TODO create function that takes in the byte array and appends the hi and low checksum bits
print(struct.pack('<h', 0xF1));

# joey based on doc trying to set to PC mode
# this doesn't really work, or at least it doesn't change the display to PC mode.
#data=bytes([0xA3,0x33,0x07,0x18,0x01,0x00,0xF6]) 
#=F4 = 11110100

# do you hear me? I think so.
#data=bytes([0xA3,0x33,0x06,0x20,0x00,0xFC]) 
# if in dL1 response: A3,04!,01,08

# start/stop session - this works if mode is set to Session which is the default when the Procyon turns on.
# but it just plays whatever session number is already showing on the Procyon display.
# there doesn't seem to be a way to change the session number programatically.
data=bytes([0xA3,0x33,0x06,0x15,0x00,0xF1]) 
#response = b'\xa3@\x04\xa1\x01\x88'
# which honestly doesnt' make a lot of sense. a1 means OK, but why is there an @ symbol in the first byte and where did the documented 0x3A second byte go. The 4th byte is the acknowledgement 0xa1 means OK.

print(port.isOpen())
print("Port opened...") 
port.write(data) 
print("Data sent")

while True:
    print("inside while")
    response=port.read(8)
    print(response)
    print ("Data Received")
    break

Sadly I'm not sure this will be useful for me unless I build a robot to control the physical Procyon hardware. I can start and stop a session, but I can't select which session to run. It just runs which ever session is showing on the Procyon Screen. Although interestingly, the Procyon seems to remember which session was selected during it's last run when I turn it on. So if I physically select session 8 using the Procyon buttons and then pull the USB cord (with no batteries inside), when I plug the usb cord back in the Procyon defaults to Session 8. So if my setup only used 1 session this would be fine. I currently have 6 sessions, so I suppose I could have 8 procyons, each set to 1 of the 6 sessions and then programmatically tell an individual Procyon to start it's session based on which one I want.

I tried sending a mode change to Session 0x00 repeatedly. I was hoping that if I told it to switch modes to the mode it's already in that maybe it would increment which session it was on. No luck.

This might be super useful for other people though. There' information on how to send segments.
Joey.

[jelwell]

Procyon AVS can "Upload Session to Procyon". Using the docs here I might be able to deduce what commands are being used to upload a session to the Procyon by cross referencing the USB commands I'm sniffing across the wire. In which case I could just reupload a session everytime and then run that session. Not sure how far into this I'll go though. For now I've been using macrorecorder to simply automate the Procyon AVS software. But running an entire PC is a heavyweight solution for my setup which is used to running off of 12v solar power and some batteries.

[Andy]

Sounds like a lot of effort to go through!
If you were using a Kasina or Limina, you could just have the tracks on your computer and stream them to the device. SO much simpler. I guess you could stream AS tracks to the Procyon too, but you'd lose the separate RGB control.

[jelwell]

Sounds like a lot of effort to go through!If you were using a Kasina or Limina, you could just have the tracks on your computer and stream them to the device. SO much simpler.I guess you could stream AS tracks to the Procyon too, but you'd lose the separate RGB control.

Partly this is fun for me. Learning serial control, and such. The amount of time it would take to convert the Procyon tracks to Limina or Kasina is a considerable undertaking. That skillset is also far outside of my wheelhouse and I haven't wanted to learn how to create sessions, let alone convert them... yet.

[jelwell]

I've been playing around with the various documented commands and I noticed the command for changing the session mode gets a confirmation from the Procyon, but doesn't change the display, nor does it seem to actually change the mode. Example, if I send a command to change to mode DAS, the Procyon responds with success, but the display still shows "008", implying Session mode.

I thought maybe an older Procyon firmware might honor that command so I wanted to downgrade the Procyon OS, I saw an older version "PROCYON_1764.PR2" in the installation folder and tried using "Update Procyon OS". But the device essentially went unresponsive and died. I did some digging around in the forums and it looks like I sent a Rev1 OS to my Rev2 Procyon. Is there any way to recover? When I plug it into my computer the Ganzframes lights all come on. But the LED display is dead.

Thanks,
Joey.