My own interface to Blu16

patrikk

Hi,

I have built a application that is used in \"conference centers\", with this application you can for example record the speeches, play music etc.

This application is built in C# and is controlled from a touch screen.

Now I have started a project to integrate controll of the Blu 16 in my application. We don't want to have both the computer touchscreen and a Blu 10.

I have managed to set the volume and mute the microphones.

But there is a problem with subscribing, when I call SET I don't get a answer to my application. I have built a server (for testing) that listens on port 1023, TCP) but no messages arrives. I called the server (from another computer on the network) with telnet on port 1023, that worked so it shouldn't be a firewall issue.

Is there something I have missed, either in my application or in the Blu-16 configuration.

Thankful for some help.

regards Patrik

Dan Lynch

http://www.bssaudio.com/phpBB2/viewtopic.php?t=329

Dan

patrikk

Hi,

thanks for the answer. I read this from the post.

\"Please download the module. BSS has invested many, many hours creating and maintaing that code specifically for programmers like yourself. This will answer many questions that you have in a very practical manner.\"

Where can I find this module and do I need some kind of login to download it.

Thanks Patrik

Dan Lynch

http://www.bssaudio.com/phpBB2/viewtopic.php?t=336

http://www.bssaudio.com/phpBB2/viewtopic.php?t=337

Dan

patrikk

Hi,

thanks I have now managed to build my own interface.
Almost everything works perfectly, I get answers to my subscribe and so on.

I have a small (but strange) problem.

After i use the SET message type I immediately use the SUBSCRIBE message type to see the status of the BLU 16. Depending on the answer I update the user interface.

Now to my problem, this works perfectly on my laptop (with Windows 7) but when I move my program to the production machine (an older desktop with Windows XP) many of the times I call the SUBSRIBE I get the \"wrong\" answer. For example even if the microphone is muted the reply for the SUBSRIBE is that the microphone is unmuted.

I have temporarily fixed the problem by putting in a small delay (100 milliseconds) between the SET call and the SUBSCRIBE call.
That seems to have solved the problem, but I don't like that solution at all.

Do someone have some ideas why this happens and how to solve it?
Thanks!

Dan Lynch

It sounds like your PC has a LIFO buffer somewhere and is sending the commands in the wrong order.

Dan

patrikk

Hi,

I tried with another computer (Windows XP) and got the same error.

I don't really understand what you mean with LIFO (Last In First Out) buffer.
Where would this be?

The strange things is that when I have the delay/sleep command between the SET and the SUBSCRIBE it works.

Thanks Patrik

Dan Lynch

I don't know anything about the differences in the way the two operating systems handle ethernet messages. One other possibility is that something is garbling the SET message. Since it's TCP, it will get sent again, but by then the SUBSCRIBE has already gotten to the destination. Try sending the SET message twice. If you send SET, SET, SUBSCRIBE, and you get back the value from before the SET messages, then you have a LIFO problem. On the other hand, if you get the correct value back, that means that it's just the first message getting messed up.

It may or may not get you any closer to knowing what's causing the problem, but at least you'll have a better idea of what exactly the problem is.

Dan

mupi2k

I am certainly no expert on windows networking but I do know a couple of things.

one is that there are pretty major changes to the network subsystems between windows XP and Windows 7. these could easily account for a few milliseconds difference in the arrival time of packets.

There's also the possibility of the differences in the hardware causing packets to transit faster or slower. One interesting experiment would be to run the program in windows XP mode under Windows7, and see if you have the same problem. If you don't, that points to a difference in the hardware causing the issue, if you do still experience the same problem, that points the network stack in the OS as the root cause.

I seem to recall as well that somewhere in the documents about the third-party control protocol that they suggest waiting a brief period between a SET and a SUBSCRIBE (or actually, between any two consecutive commands), to allow the box time to process the SET. However I can't find it now, so I'm probably misremembering.

patrikk

Thanks for the answer.
I have used my system in production now a couple of weeks.

I have had no problem when I inserted the delay/sleep. The delay is so short that it doesn't affect the system behaviour.