Any updates (SCC1 MJS working under Linux)?
I have been trying the perl module "Audio:Radio::Sirius" with no luck... gave up on that at the moment.
Started from scratch with C/C++ code using <termios.h> and using interceptty to sniff the serial port, I can see the first bytes "0xA0 0x03..." sent, but never get anything back...
Anyone tried this and made more progress?
I abandoned fixing the Python version that I had for a few reasons - it was buggy, I don't really know Python, and eventually I want to have this running on Android. I ported it to C++ a couple months ago and managed to work out the bigger bugs (from what I can tell), including figuring out a few of the inconsistencies with the Perl module that I was working off of.
I've attached the code. You may have to run:
sudo /sbin/modprobe ftdi_sio vendor=0x0403 product=0xca81
(I remember having to do that when I was working with the Python stuff, but it's been a while, so I'm not sure if that's still necessary or not.)
Let me know if it works for you.
Thank you very much!
This is alot farther than I had progressed on my own. Much appreciated.
I will let you know how it goes.
If I run this command
"stty -F /dev/ttyUSB0 raw ispeed 57600 ospeed 57600 cs8 -ignpar -cstopb -echo"
and then run the program, I get some a couple of ACKs and then gets stuck on the second "Received Command" at line 184.
It does not successfully start the channel.
How far do you get with the code (does it successfully tune a station?)
It USED to tune to a station and properly read all the data (station, song, artist, etc).
I am now experiencing the same problem. I'm wondering if the protocol changed recently. I'll post back if I can figure out what's going wrong. Sometimes it tunes to a station, but none of the requests are coming back from the tuner properly.
are you guys dealing with the ESCAPE Sequence?
i dont think that python code had anything to handle it
just a fyi, the protocol hasnt changed...
i havent looked at sirius protocol in a few years...
i think if i updated my comm dll to support that wierd device string of linux to spec comport, it would work in MONO
Yeah, the C++ code deals with the escape character (just reads and throws away the next character when it sees character 27). I think I was just having trouble with the serial port or something - not receiving the 0xA4 0x03 characters that were starting the commands from the device.
It's still flaky though, and I'm trying to work through the details. Most of it just deals with getting the protocol right.
I think I found the culprit: the serial port needs to be opened in non-blocking mode. I'm guessing I previously had setup my serial port to be opened in this mode by default, but just guessing. Anyway, fix is to replace:
open(port, O_RDWR | O_NONBLOCK)
you dont want to throw away the next char!
$1b $1b = $1b
$1b $53 = $a4
with out this you will fail a lot!
remember to escape on transmit too
bottome line no $a4 allowed in the bytes other than header
and checksum is calcuated before the escapes in transmit
i just looked at your code
its wrong, and just too simplistic
anyway... keep at add it, do the proper esc seq i just showed you