Velodyne DD-10/12/15/18 Driver

[dcpete]

I presume no one has had a need to write this driver, since I don't see it anywhere? I just replaced my old ULD-15 Velodyne with the latest generation DD-15. It is sweeet! Anyway, it comes with it's own parametric equalizer with mike, so you can equalize to your room. It also comes with a remote so you can adjust sound fields, volume and other things. I just looked at the Serial interface and it is well done. It's two way, fairly simple and comprehensive. CQC control is really needed because you need to have a video display hooked up to it to see what the volume and pre-set equalization settings are. And normally you want a sub to just sit in a corner invisible. I guess I'll start working on the driver unless someone has been secretly working on this already.

Thanks, Chris

[jrlewis]

Chris,

I have just written a driver that supports the SMS-1 and the SC-1250. It needs a little polishing, but it is essentially ready to go. The published protocol is straightforward, but we have come across an error in the published protocol as well as some oddities. The protocol for the DD series is the same, except it supposedly has a different response message than the SMS-1 or SC-1250 that isn't reflected in the published protocol.

To verify what they told me can you connect it to Hyperterminal and try out a couple of commands. The main thing I need you to verify is the form of the response from the sub. First off you may need to change the DataBits to 8 instead of 7. The SMS-1 and DD's are listed as having 7 DataBits for the configuration, but the SMS-1 is actually 8 and this may be the case for the DD series as well. Try sending it a request for things like power (#JU?$), Mute (#MU?$), Volume(#VO?$), etc. According to the guys at Velodyne it should respond with something like %#JU1$, %#MU0$, etc. They supposedly changed the response of the DD's by prepending a % to deal with some issues when having the DD's daisy-chained together in a slave/master setup. In particular send a volume command and look for the response from the sub. The remote and sub only support up/down while you can directly set the volume via the serial protocol. The pain of it is though when you send a direct volume level it appears to implement it on an incremental basis and you get a series of incremental responses back. Say you are at a volume level of 5 and you send #VO15$ the SMS-1 returns #VO06$#VO07$#VO08$,...,#VO15$. Also try changing around the presets and changing the volume level.

While the presets can each have their own volume in the setup, when you change the volume via the serial protocol it is adjusting the master volume and each preset channel changes incrementally. If you were at a level of 5 and you went to 10 all the volumes for each preset would increase by 5. It gets really wierd when the presets don't have the same volume in the setup and you are below a level that is smaller than the largest differential of the volume presets. It does some very strange things that I think I have partially figured out, but am still waiting on some feedback to make sure. So if you are playing around with volumes at low levels and get a long series of VO00 and it finally levels out then I'm betting the presets have different initial volumes inside the setup.

Once you verify what the response is I can change the driver if needed and get you a copy. This would make it nice to get another beta tester going on it.

[dcpete]

Ok, that's cool. Yes I can confirm that my doc's do state data bits=7. Wow, that is a pain that they send incremental responses back. Is it a noticable delay from the user point of view? Say from going to volume 20 to volume 35? Nice though that you can set the volume in one command. They show no examples of how the responses show up. So that's nice you have been through this already. I will get back to you after I get my serial port emulator up and running again, maybe in a few days or next week.

Chris

[jrlewis]

I don't actually own the SMS-1, but I believe the volume change on the unit is basically instaneous. It is just the response buffer that takes some time to eat through. For volume changes I was initially going to chomp on the buffer until it didn't contain any more volume events so the volume field was in synch with the device. When I ran into the issues with the low level volume setting with unequal presets the driver could potentially get stuck in a loop on volume changes so I decided to ditch that (don't know for sure if its the unequal preset volumes...but it appears to be that). The volume events along with the rest are just processed in the Poll method and from what I could see a volume change of 20+ is where you start to see some "flutter" in the volume field within CQC. It has no effect on the volume for the device. The person with the SMS-1 says he doesn't take it much higher than 15 so it may be a non-issue. This may be the one place where a queued write would be appropriate given the nature of the repsonse from the device, but I'm just leaving it as is for now.

[dcpete]

I don't actually own the SMS-1, but I believe the volume change on the unit is basically instaneous. It is just the response buffer that takes some time to eat through.

Makes sense. You don't really even need to process the response buffer. It could be done with a timer, or some other keep-alive event. Yes, it probably is instantaneous.

Chris

[dcpete]

Ok. I have figured out this protocol. The response commands are not documented, but I can state what I observe and I have figured out almost everything. I'll provide you with the information and let you map it to what you already have. Feel free to ask me to check out anymore commands if necessary. I have my test system all set up and the Velodyne is responding predictably.

First of all, the DD-15 always sends a keep-alive sequence when not processing a command. Sometimes this keep-alive sequence is the response because it contains status on all the Velodyne settings. The format of the keep-alive response is -

#%BLlvvpnm$

Where <BL> - Command Response
<l> - Logo Light Status (0 or 1)
<vv> - Volume level (00-99)
<p> - Preset mode (1,2,3,4,5 or 6)
<n> - Night mode (0 or 1)
<m> - Mute mode (0 or 1)

As an example, the response string "#%BL126400$" means Logo light is on, Volume is 26, Preset mode is 4, Night mode is off and Mute is off.

This sequence repeats over and over again when no command is being sent. In other words, it is a keep-alive with important status information contained in the string.

To confirm what you mentioned about the volume control. I ran an experiment to change the volume from 31 to 41. Here is what I got -

#$VO32$
#$VO33$
..
..
#$VO41$

As predicted....

Sometimes a command that changes the state is essentially echoed in the response string. But again always followed by the keep-alive string. For example a Power off command of "#JU0$" will yield a response of "#%JU0$", followed by the keep-alive string. A query of the power state with the command "JU?$" will yield a "#%JU0$", followed by the keep-alive string repeated.

Let me know if there is anymore detail you require? You mentioned about daisy-chaining the DD series. Indeed, this can be done. There is a serial in and out port. I gather from reading the manual that when in this mode of master and slaves, all the subs in the chain react to the same command and the master only responds to the command. It does not seem possible to have different subs on the chain programmed independently of each other. That being the case, there seems to be no provision of a unit number in the protocol. None that I've seen by reverse engineering anyway.

Hope this helps and I would be delighted to "beta test" your code.

Chris

[jrlewis]

First a few questions...How often is the "keep alive" status code being sent and for the volume change did you mean they are #%...$? If you turn the unit off via the protocol does the "keep alive" status continue to transmit? Can you also confirm that when the power is off it won't accept any action commands other than a power command. With the sub connected and communicating try changing the volume directly on the sub and turn the unit off on its back panel and see if the device communicates the volume changes and power off and whether this affects the status code being transmitted. One more thing...what did you use for the DataBits for the config?

[dcpete]

did you mean they are #%...$?

Sorry, my mistake. Yes all the response string start with a "#%" and end with a '$'

How often is the "keep alive" status code being sent?

About every 10 seconds.

If you turn the unit off via the protocol does the "keep alive" status continue to transmit?

Yes.

Can you also confirm that when the power is off it won't accept any action commands other than a power command.

That's correct, when the power is off, it does not accept any other commands besides power commands. It looks like if a command is accepted, it will echo the state back in the response format. For example a Power off command when the power is off will return a "#%JU0$" before sending the normal keep-alives every 10 seconds. To summarize what happens when the power is off -

Power off command sent ==> #JU0$
Power off state received<== #%JU0$
Keep alive received <== #%BL041100$
..... (repeated every 10 seconds)

Power status command sent ==> #JU?$
Power status state received <== #%JU0$
Keep alive received <== #%BL041100$
.... (repeated every 10 seconds)

Power on command sent ==> #JU1$
Power on state received <== #%JU1$
Volume level received <== #%VO41$
Power on state received <== #%JU1$
Keep alive received <== #%BL041100$
.... (repeated every 10 seconds)

Note that a power on command when the power is off also returns the volume level followed by an additional Power On State response.

what did you use for the DataBits for the config?

DataBits 8.

Chris

[jrlewis]

Interesing...definitely different than the SMS-1. I just need to adapt the logic to deal with the extra start character and status message. I had planned on the extra character and the status message won't be a problem.

How about the port config? Is it 7 or 8 DataBits?

[dcpete]

Sorry I edited my post after you saw it. Data bits was 8. I also started playing around with the response on the serial connection using the remote. It is predictable, but a little different. It does not echo the state back twice when turning the power on from the remote. For example, I see this sequence when powering up by the remote -

Power on command sent ==> #JU1$
Power on state received <== #%JU1$
Volume level received <== #%VO41$
Keep alive received <== #%BL041100$
.... (repeated every 10 seconds)

Note there is no Power On State receieved AFTER the volume level received, unlike if the same command was issued by the serial port.

Chris