Sirius SC-H1
BCalderwood
Posts: 35
We had seen one of these at CEDIA working with a Netlinx processor via RS-232 on a 12" Modero. Bought one and we can't get any info on the pin out. It uses an 8 pin din and any info would be great. Thx in advance.
0
Comments
I've got one sitting on my desk, and it came with the Din->9 pin Dsub cable. I'm not in the office today; with any luck I'll remember this post tomorrow and I can trace the pins for you.
I just ordered the SCH1P2 from Crutchfield and it comes with an RS232 cable for integration with AMX. Granted, it was $90 - but I needed it quickly and it looks like it should work.
There's a non-duet version floating around somewhere here on the forums, perhaps you can grab that if you don't want to go with the duet version.
Any link on this? I searched and couldn't find anything. A module non-duet module for the SCH1 would be fantastic.
http://www.amxforums.com/showthread.php?t=2578
It's non-AMX verified and written by someone here on the board. I haven't tested it out, but will once we get the piece.
What? Huh?
Can't get to it
Tips & pointers appreciated.
Well, it's definately a piece we'd use again, that's for sure. For the price, it's pretty decent. I wound up using the Duet module only, and didn't try the NetLinx version at all. I found that using it would have been too much work since it wasn't in a modular format, and I needed to wrap up the job that day.
I'm thinking about making some modifications to the NetLinx code to make it a module. Though I never tested it out to begin with, so that may create some problems. The nice thing about the piece was that I was able grab feedback from it without having to activate it. I just could hear the audio from it was all, but the feedback updated as if it was activated.
I'd reccomend this piece if anyone's looking for a Sirius piece to use in their system. And like I said - for the price, it's great. We got the SC-H1P2 from Crutchfield for $96 (that included shipping). We now have both inexpensive Sirius and XM pieces to offer our clients and that makes us happy.
Jeremiah,
If you get the time I'd really appreciate letting me know if the Netlinx module works with the kit you bought from Crutchfield - if so I'll probably go ahead and order. As I mentioned earlier I'm working with a non-duet system, so I was originally planning on a DT1000, but I'll buy this if it works out.
Thanks!
Dan
I'm not sure of when we'll get that piece again. Most of our clients prefer XM, but since I'm a Sirius subscriber - I may buy one for me, and test it out with AMX before I install it in my home.
I'll keep you posted.
Does anybody have the pinout for this unit? I ordered one from eBay and the guy sent me the SCH1P1....it gets worse! I then ordered one from Dog Star Radios and they also sent me the wrong one! When I contacted them they said we are out of stock on the SCH1P2s. So happy they sent me a cheaper one and charged me FULL price for the SCH1P2. I am desperate to get the pinout for the RS232 cable. I am hoping to take the cable that came with the unit and create my own.
DB-9 Female DIN
2
8
3
7
5
6
None of my DIN connectors have numbers on the pins, so this is probably not standard notation - I called pin 1 the top left connection when looking at the SC-H1 and went left-right, top-bottom. So the pins used are the bottom two, and the far right one on the second row from the bottom (ground).
Steady Red = Initial power on indication
Flashing Red = Antenna not connected
Steady Amber = Antenna connected but no signal
Steady Green = Antenna and signal are good.
I have the SC-H1P2 and when I applied power to the unit the indicator light turned on to a steady red. I figured after the initial power on indication I should get one of the next three colors however the color never changed.
After I read through the protocol I found out that the SC-H1 sends a ready message when power is applied and then the RS-232 controlling device needs to send a set power command. When I wired everything up and sent the power on command the indicator light changed to a steady green and life was good.
How are you applying power to the unit? There is a special note that says not to apply power to the front of the SC-H1 if you are using the RS-232 cable. You have to apply power to the female jack that is on the RS-232 cable itself.
Regarding the audio jacks on the SC-H1 and the audio plugs on the RS-232 cable, both sets work. I?m using the jacks on the SC-H1.
If you don?t have a subscription then the only station you will hear audio on is channel 184 which is the preview channel. If you go to channel 0 the song name will be the Sirius ID of the SC-H1.
I tried the DUET module but opted to roll my own. There was too much chatter with the DUET module because it looks like it doesn?t handle the software handshaking properly.
I also didn?t like the way it handled the signal quality because it uses the send_command/send string paradigm. I wanted to use a level event instead. The module also didn?t implement the audio loss notification you can get from the SC-H1. I was happy to see channel events for station/category up and down. I feel it?s much easier to use channel and level events instead of parsing send_strings and doing send_commands.
I didn?t do any long term testing with the DUET module but it does work and I?m sure it?s fine even with he extra chatter. I just wanted to do it myself so I would have the source.
< Antenna rant>I did have some trouble with antenna placement. I couldn?t get to the roof so I placed it outside where the SC-H1reported back with a strong signal. When I got everything up and running and was confident in the operation, I told my wife about Sirius and how cool it was. I took her to the touch panel and showed her how it works hoping she would share my excitement. And right at that time Murphy?s Law smacked me in the face and the audio started cutting in and out. My wife sarcastically gave me a yeah that?s really cool Then a little while later the audio locked back in but it still dampened the thrill. I started logging the signal quality and audio loss and noticed that I lost audio several times a day at about the same time each day. I moved the antenna again until I found a sweet spot that locked in 24 hours a day with the satellite that hangs over Minnesota. I guess this is all just a long winded way of saying that even though you might have an excellent signal at the time you are mounting the antenna (that doesn?t sound right) you may not have a signal later in the day. Best bet for sure is on the roof with a wide open look at the sky in all directions. < /Antenna rant>
I never thought I would live to see a day where I would pay so much money to watch and record TV and pay to drink bottled water (Evian is naive spelled backwards and I read that the name was chosen on purpose) and there was no way I was going to pay to listen to the radio but I have to say I?m hooked on Sirius.
All babbling aside, I hope some of this is helpful.
The indicator light has never come on. I think I missed that note on not using power on the SCH itself. That could explain things. Do you have the pinout for the power section of the 8 Pin DIN connector? I read on some other forums that you need to use RS232 line drivers with this unit and not just a straight RS232 solution. Are you using the SCH1P2 or a custom cable solution?
This is a sample of the debug info captured from the module (it does show the set power command, although nothing happened:
Line 762 (19:58:10):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: handleDataEvent()
Line 763 (19:58:10):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: Comm <
device: INCOMING DATA 'FA'
Line 764 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: Response timer timed out.
Line 765 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: lockQueue(false)
Line 766 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: reinitialize()
Line 767 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: DeviceUtil.reinitialize() called
Line 768 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: getProperty(Timeout_Count) = 3
Line 769 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: lockQueue(false)
Line 770 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: class java.lang.Class.reinitialize()
Line 771 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: class java.lang.Class.reinitialize()
Line 772 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: class java.lang.Class.getTunerStationComponentIndex()
Line 773 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: handleOnlineEvent()
Line 774 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: DeviceUtil.handleOnlineEvent() called
Line 775 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: setCommPort()
Line 776 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: setPowerMode(3)
Line 777 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: enQueue(a4030119000300080331)
Line 778 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: DeviceUtil.restartQueueTimeline() called
Line 779 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: enQueue(a403011a00024007f5)
Line 780 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: DeviceUtil.restartQueueTimeline() called
Line 781 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: enQueue(a403011b1b00024018e3)
Line 782 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: DeviceUtil.restartQueueTimeline() called
Line 783 (19:58:15):: com.amx.duet.impl.sirius.scht.dr1_0_0.SiriusSCHTuner: Comm sent to device: a4030119000300080331
I agree with writing your own module. I would love to tackle this protocol, just a little intimidated from what I read (you know....the 140 page Sirius manual). Once I get something working, I will certainly take on the challenge (love challenges!).
The antenna rant...love it....I thought it was just me! I went through similar experiences setting up my antenna. I am currently using a Sirius Stiletto and am sick and tired of having multiple TPs around the house and controlling something IR
Hope this lengthy post can make some sense as to what might be happening.
I wouldn?t dream of making that cable. I don?t have the patience, the eyesight, or correct info to even attempt it. It?s just not worth my time. I bought the SC-H1P2 from tss radio and got it for $79.99 (tuner, RS-232 cable, power supply, and outdoor antenna) with free shipping (anywhere in the USA) and received it next day (they are local to me)
http://www.tss-radio.com/sirius-connect-home-tuner-pro-kit-sch1p2-p-4422.html
Did you send a change a property command to the DUET module to change what AMX is calling the Device ID? (The protocol uses the term MODID)
The first two bytes are correct $A4 and $03 but the third byte should be $00 by default, not $01. The third byte is the MODID and the tuner is set at $00 by default and the DUET module uses $00 by default also. If the module is asking to talk to MODID 1 and the tuner is set to 0 then the tuner won?t respond.
It helps if you read the 123 page implementation guide first. It?s one of those protocols that when you read it the first time you think to yourself ?WTF, could they have made it anymore complicated!?? But after you read it over and over the pieces start falling into place and you begin to see the method to the madness. When that happens you realize how well thought out, robust, and elegant the protocol really is. And once you learn how to do one command the rest are a breeze. Obviously the first one is the toughest.
Here are a few tips that might help to get you started should you decide to take on the challenge.
All commands/responses are variable in length and have no terminating byte which does complicate matters. Be aware that you will definitely not receive an entire message at once all the time so you have to account for that.
Protocol format
Byte 1 is called the SYNC byte and is always $04.
Byte 2 for this product is always $03.
Byte 3 is the MODID which as I mentioned earlier is $00 by default.
Byte 4 is the sequence number and is used to uniquely identify the transmission. You decide what the sequence number should be. When you send a message to the tuner (including any retries if necessary ? 3 is the recommendation) the same sequence number will come back to you in the response. You keep track of the last sequence number you sent and when you send a new message you increment the sequence number by 1. You can start with $00 and inc from there. When you reach $FF you go back to $00 again. When the tuner sends a message type transmission to you, you use the sequence number it sent in the ACK you send back.
Byte 5 specifies what type of transmission it is. It can either be an ACK ($80) or a Message ($00 ? this is where all your parsing will take place) or two types of NAKs ($82, $83.) When you receive a Message type transmission you are supposed to ACK it back. The DUET module didn?t implement any ACKs so the tuner always retries every message it sends 3 times, hence the extra chatter I mentioned in my previous post
Byte 6 is the LEN byte. This will tell you the length of the remaining bytes (the payload) not including the checksum. The length of an ACK or NAK is 0.
The Payload This is meat of the transmission and varies as per the protocol. A summary of all the commands are on page 24.
The Checksum is the 2?s compliment of the sum of all the bytes prior to the checksum. You calculate it by adding all the bytes (lopping everything over $FF since it?s only a one byte checksum) and then BNOT the answer and add 1. The checksum is calculated prior to byte stuffing.
Byte Stuffing
Since a $04 marks the beginning of a transmission that means that a $04 can?t exist in any other part of the message. So how do you use $04 if you need it (and you will) as part of the message? You byte stuff. After a command string is built and before you send it out you need to replace every $04 within the entire command (except of course for the first byte ? the Sync byte) with an ESC character ($1B) and a capital ?S? ($53). And since the ESC character now marks the presence of a special character (the $53) that means if we have a $1B anywhere else in the message we need to ESC the ESC so we replace every $1B in the message with a $1B $1B. The order you do the stuffing matters. First you replace every occurrence of $1B with a $1B $1B and then you go through and replace every occurrence of $04 with $1B $53.
Byte Destuffing
When the tuner sends us a command we have to destuff any byte stuffing that the tuner may have needed to do. And we have to do it before the command can be framed and interpreted since the byte stuffing will alter the length of the message and the validity of checksum. The order of destuffing matters also. First we replace any occurrence of $1B $53 with $04 and then we replace any occurrence of $1B $1B with $1B.
Parsing a transmission
Let?s interpret what the DUET module sent to the tuner. First we need to destuff. I don?t see a $1B $53 or $1B $1B so no stuffing was done so there is nothing to destuff.
$A4 = sync byte
$03 (byte 2 is always $03)
$01 = MODID
$19 = the sequence number
$00 = I?m a message type of transmission
$03 = there is a 3 byte payload
This is the payload:
$00 $08 $03
There are 5 different types of payloads. There are GETs (we want to find something out), SETs (we want to change something), and PUTs (unsolicited feedback from the tuner) We can do GET and SET. The tuner can respond to a GET, respond to a SET, and do a PUT.
.
The first two byes of the payload are called the opcode and the 3 most significant bits of the 2 byte opcode tell you which one of the 5 different types of payloads it is. Since the first byte is $00 we know that the 3 most significant bits are 0 and by looking on the chart on page 22 we see that this transmission is a SET command to the tuner.
Now we go to the summary of opcodes on page 24. We look for 0x0008 and we see that it?s a SetPowerMode command and that command is described in section 5.6.2.1.1. So we go to that section which is on page 59. We see that this command takes one more byte which in this case was $03 and we see that it means that we want to set the power to full on.
$31 is the last byte which is the checksum.
If we add up all the preceding bytes we get $CF. We then do a BNOT and add 1 which gives us the $31.
NOTE: If you use the REPLACE_STRING function from Tech Note 661, DON?T
.
While I was developing and testing the SC-H1 code I came to a point where my NI-700 locked up solid and I couldn?t for the life of me figure out what the heck I was doing so drastically wrong. I had already tested several commands and at this point was just adding functionality that reused a lot of the same functions that I felt were rock solid. I spent hours trying to figure out where I screwed up. I stared adding more debug messages, watching variables, and adding break points in the module (breakpoints and stepping through code in a module is an absolute pain and I sure wish it would get fixed) Then the light bulb finally went off and I realized that the AMX REPLACE_STRING function (that I have been using for years without problems) that I call in my byte stuffing function actually had to do a replace of a $1B with a $1B $1B for the first time. I then looked the function over and quickly realized that the author didn?t account for replacing a character with two of the same characters and it got stuck in a while loop that made the string grow and grow and eventually killed the NI and nearly killed me.
Lengthy? Pfff! If anyone else has insomnia like I do, this post will surely put them to sleep.
I have ordered a SCH1P2 kit and it should arrive tomorrow morning (nice Christmas gift to me ). I believe this to be the source of much frustration for me.
Sorry, I did send a property change to the module when $00 (default) wasn't working. I mistakenly copied the text AFTER changing this.
You are right, the more you read through what they (Sirius SPP) have done the more you realize how it is accomplished and in fact, how well thought out the structuring is.
Thanks for all your help. Once I confirm that I have proper communication to the new tuner, I will undertake writing my own module. It would be a great learning experience. The longest and most string parsing module I have written was for a VERY big Lutron P5 (ethernet) lighting project, so this will be a welcomed addition to the library.
Keep up the great posts!
The SC-H1 is indeed a solid product at a bargain price. Now that I have commercial free music I don?t know what I?d do without it.
Regarding the sequence byte, I don?t remember doing anything special with it. I just let it roll over.
It?s good to hear that I?ve been of some help with your progress in Netlinx. If you?re ever in the Chicago area, give me a shout.
Also, does it allow me to see what is playing on other channels without tuning to them? One feature I really like on my Sirius is that it will alert me when a favorite artist or song is on and give me the option to switch to the correct channel.
Thanks,
Jeff
Yes, the protocol supports browsing; however, I haven?t implemented that yet. I?m pretty sure anything you can do with your Sirius tuner can be done with the SC-H1 if you?re willing to spend the time coding it. I may be wrong but I believe the protocol is the same across devices.
This option has a blue readout that compliments any rack decor
Jeff