AudioNet (invalid format errors)
Just wondering if anyone else is having similar issues with their AudioNet. Recent (not sure when it began) a majority of my saved stations fail to play (invalid format) but play just fine via Winamp. I have tried entering them manually both with mp3 and ACC, all fail. BTW, this is for BBC Radio 1&2 and Downtown Radio from Northern Ireland in case some else wants to try. Also running firmware 1.002.0101 on a AMS.
Thanks in advance for any help or directions.
Regards,
Peter
|
Re: How would you parse this data?
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@...> wrote:
Yeah, right, the string is not always the same,
Matt, What device is this, so we can think REALLY bad thoughts about its designer... Chris K.......:)
|
Re: How would you parse this data?
Thanks OP, that's exactly what I mean, is it worth the time to do that vs. just using remove. I know what you mean though...
The attenuation is taken as a string, and will have a space at the end, which isn't critical for me. But yes, if I wanted an integer I would have to check the first byte to see if it's 0x2D and then either -ATOI or just ATOI the group.
toggle quoted message
Show quoted text
--- In Crestron@..., "olly_penguin" <oliver.hall@...> wrote:
Hi Matt,
That looks like a classic candidate for a state machine.
I.e. rather that attempt to parse a complete message in one mouthful, implement a routine that eats numbers, delimited by white space or the lf/cr.
Lf/cr resets the state machine and spits out your interesting data, and for each "number" you maintain a couple of state variables (data chunk, sub element).
And Atoi won't work on negative numbers will it?
Sorry this is a bit brief/vague, but I hate typing on my phone :)
All the best,
Ol
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:
Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.
--- In Crestron@..., "jrw_96" <jrw_96@> wrote:
Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always \x0d\x0a...
If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...
JRW
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:
Here's the string
0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0\x0d\x0a
The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0
the first set of chars before the first space can be 0...-100, all the other data is a single byte.
My method is using REMOVE statements like below
status1 = ATOI(REMOVE("\x20", rx$);
status2 = ATOI(REMOVE("\x20", rx$);
status3 = ATOI(REMOVE("\x20", rx$);
Attenuation[1] = REMOVE("\x20", rx$);
ch1Clip[1] = ATOI(REMOVE("\x20", rx$);
etc.,
all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?
|
Re: How would you parse this data?
Hi Matt,
That looks like a classic candidate for a state machine.
I.e. rather that attempt to parse a complete message in one mouthful, implement a routine that eats numbers, delimited by white space or the lf/cr.
Lf/cr resets the state machine and spits out your interesting data, and for each "number" you maintain a couple of state variables (data chunk, sub element).
And Atoi won't work on negative numbers will it?
Sorry this is a bit brief/vague, but I hate typing on my phone :)
All the best,
Ol
toggle quoted message
Show quoted text
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@...> wrote:
Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.
--- In Crestron@..., "jrw_96" <jrw_96@> wrote:
Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always \x0d\x0a...
If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...
JRW
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:
Here's the string
0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0\x0d\x0a
The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0
the first set of chars before the first space can be 0...-100, all the other data is a single byte.
My method is using REMOVE statements like below
status1 = ATOI(REMOVE("\x20", rx$);
status2 = ATOI(REMOVE("\x20", rx$);
status3 = ATOI(REMOVE("\x20", rx$);
Attenuation[1] = REMOVE("\x20", rx$);
ch1Clip[1] = ATOI(REMOVE("\x20", rx$);
etc.,
all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?
|
DSI Entertainment Systems Hiring in Los Angeles
DSI Entertainment Systems is looking for a full time Control Systems Programmer.
Programmer should be comfortable with commercial, residential, and lighting
programming. Benefits include a competitive salary, medical and dental
insurance, paid vacation and holidays. Please send resume, example programs, and
salary requirements to dbransford(at)dsientertainment.com.
|
Re: How would you parse this data?
I vote for splitting hairs. If you *want* all of the data that's in there, the ATOI(REMOVE looks like the way to go.
- Chip
toggle quoted message
Show quoted text
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@...> wrote:
Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.
--- In Crestron@..., "jrw_96" <jrw_96@> wrote:
Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always \x0d\x0a...
If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...
JRW
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:
Here's the string
0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0\x0d\x0a
The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0
the first set of chars before the first space can be 0...-100, all the other data is a single byte.
My method is using REMOVE statements like below
status1 = ATOI(REMOVE("\x20", rx$);
status2 = ATOI(REMOVE("\x20", rx$);
status3 = ATOI(REMOVE("\x20", rx$);
Attenuation[1] = REMOVE("\x20", rx$);
ch1Clip[1] = ATOI(REMOVE("\x20", rx$);
etc.,
all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?
|
Re: Wireless battery powered wall mounted keypad?
Urc kp900 using the Crestron rf hack?
toggle quoted message
Show quoted text
--- In Crestron@..., "Mark" <access@...> wrote:
Unfortunately not - it's a solid wood orangery with no way to get supply or network cabling..
--- In Crestron@..., "ChrisK" <chris@> wrote:
No 110v electric near by? a wireless cameo KPD would work...
--- In Crestron@..., "Mark" <access@> wrote:
I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.
However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.
Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)
There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.
Has anyone got any idea of any elegant hardware I could use?
Cheers.
Mark
|
Re: How would you parse this data?
Yeah, right, the string is not always the same, like I said, the attenuation value can be from 1 to 4 bytes long, for each channel. I was thinking of getting the LEN of the attenuation data, then MID the string based on that but seems more work than the removes anyway.
toggle quoted message
Show quoted text
--- In Crestron@..., "jrw_96" <jrw_96@...> wrote:
Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always \x0d\x0a...
If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...
JRW
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:
Here's the string
0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0\x0d\x0a
The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0
the first set of chars before the first space can be 0...-100, all the other data is a single byte.
My method is using REMOVE statements like below
status1 = ATOI(REMOVE("\x20", rx$);
status2 = ATOI(REMOVE("\x20", rx$);
status3 = ATOI(REMOVE("\x20", rx$);
Attenuation[1] = REMOVE("\x20", rx$);
ch1Clip[1] = ATOI(REMOVE("\x20", rx$);
etc.,
all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?
|
Re: How would you parse this data?
Use a buffer and collect everything in said buffer. Then just break it down as necessary. Only if the incoming strings are predictable and/or the end of the string is always \x0d\x0a...
If the above is true then this should be gravy for you. It's when you do NOT have set points (delimiter(s) and actual sub-headers differentiating the substring/channel info) [always seems to be my case with crc's and what not] that you have to wonder "is this really worth it" imo...
JRW
toggle quoted message
Show quoted text
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@...> wrote:
Here's the string
0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0\x0d\x0a
The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0
the first set of chars before the first space can be 0...-100, all the other data is a single byte.
My method is using REMOVE statements like below
status1 = ATOI(REMOVE("\x20", rx$);
status2 = ATOI(REMOVE("\x20", rx$);
status3 = ATOI(REMOVE("\x20", rx$);
Attenuation[1] = REMOVE("\x20", rx$);
ch1Clip[1] = ATOI(REMOVE("\x20", rx$);
etc.,
all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?
|
How would you parse this data?
Here's the string
0 0 0 0 1 0 0 0 0 0 0 0 -44 0 0 0 0 0 0 0 0 -27 0 0 0 0 0 0 0 1 -26 0 0 0 0 0 0 0 0\x0d\x0a
The first three 0's are status of the device itself, then the next group of 9 (not including spaces) are individual channel data. So channel 1 = 0 1 0 0 0 0 0 0 0
channel 2 = -44 0 0 0 0 0 0 0 0
channel 3 = -27 0 0 0 0 0 0 0 1
channel 4 = -26 0 0 0 0 0 0 0 0
the first set of chars before the first space can be 0...-100, all the other data is a single byte.
My method is using REMOVE statements like below
status1 = ATOI(REMOVE("\x20", rx$);
status2 = ATOI(REMOVE("\x20", rx$);
status3 = ATOI(REMOVE("\x20", rx$);
Attenuation[1] = REMOVE("\x20", rx$);
ch1Clip[1] = ATOI(REMOVE("\x20", rx$);
etc.,
all the way through the string. Not sure if it's even worth going through breaking up the string into channel groups and working on it that way. What do you think, splitting hairs?
|
Re: Crosspoint has stopped functioning
Awesome, thanks Heath and yes I will most definitely report it...
toggle quoted message
Show quoted text
--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:
Band-aid: PERIODICREBOOT ON
There is a secondary command which changes the time of the reboot, but I can't remember it. It defaults to 2AM apparently, and it's supposed to do it "quietly" without lighting up the screen.
Make sure you report this, please. This is major and I can't believe it's still floating around after many weeks.
On Apr 26, 2013, at 9:06 AM, innoventgroup <innoventgroup@...> wrote:
Fellers,
How to I turn that on... I want to set that up, I cant afford for the panel to die again, now that the customer thinks it is fixed. Thanks Heath for explaining that and, now that you have, I have definitely experienced that scenario. As a matter of fact, I am still experiencing that scenario even after the update on the firmware, just not as dramatic as shutting down my crosspoint. Basically what it is doing now is that the serial and analog signals do not update with the rest of the system. For instance, I can use one of the iPads and change the radio station. Then I can go to another iPad and the station readout will show the updated value. But, when I go to the TSW-750s, I have to press a button to get them to update. Just some additional data for you.
Thanks again!!
DAVE
--- In Crestron@..., Neil Dorin <neildorin@> wrote:
I was mostly referring to the associated reboot fixing it.
Thank to you Heath, I turned periodic reboot on on 80 panels Tuesday and it seems to have helped immensely!
Sent from my iPhone
On 2013-04-25, at 9:14 PM, Heath Volmer <hvolmer@> wrote:
On Apr 25, 2013, at 9:02 PM, Neil Dorin <neildorin@> wrote:
My bet is its the FB bug with the TSWs and the firmware update and resulting reboots corrected it...
I was just going to say that - but do we know that the update actually fixes it? I've been pretty deep into that particular problem and have been asking if it had been fixed. I'll stick with the daily reboots!
Dave, what we're referring to is a lovely bug where the TSW just stops responding to the feedback it's receiving. It transmits fine, but completely ignores all feedback until rebooted or sending in a new program - any activity that resets Core 3. It just appears stuck. Quite elusive. I don't know if I'm experiencing it any more because the panels are now set up to reboot themselves every day...
Heath
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
|
Re: Wireless battery powered wall mounted keypad?
Unfortunately not - it's a solid wood orangery with no way to get supply or network cabling..
toggle quoted message
Show quoted text
--- In Crestron@..., "ChrisK" <chris@...> wrote:
No 110v electric near by? a wireless cameo KPD would work...
--- In Crestron@..., "Mark" <access@> wrote:
I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.
However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.
Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)
There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.
Has anyone got any idea of any elegant hardware I could use?
Cheers.
Mark
|
Re: Wireless battery powered wall mounted keypad?
No 110v electric near by? a wireless cameo KPD would work...
toggle quoted message
Show quoted text
--- In Crestron@..., "Mark" <access@...> wrote:
I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.
However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.
Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)
There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.
Has anyone got any idea of any elegant hardware I could use?
Cheers.
Mark
|
Wireless battery powered wall mounted keypad?
I've got a system with 4 zones of garden lighting which are controlled via Crestron primarily on Mobile & Mobile Pro G.
However, we need to fit a wall station of some description in a location where cabling is impossible to control them as well.
Something like a cameo keypad would be ideal, but they all need cabling of one sort or another (I know there's a battery powered infinet keypad on the cards, but it's not been released yet to my knowledge)
There is a Pro2 nearby, so I'm thinking of a battery powered wireless solution somehow connected to the versiport inputs of the Pro2 and go programatically from there.
Has anyone got any idea of any elegant hardware I could use?
Cheers.
Mark
|
Re: Discovery of idoc issue.
I have now made a connection to the idoc via serial cable and then by using the toolbox device tree view and the correct com port.
I then right click on the idoc device and select functions.... Where do I go from here to make this device discoverable via the composer wizard.
If I select Ethernet addressing it shows IP address as 192.168.0.4 with dhcp not ticked.
Or if I select ip table setup it shows me ...
Ip Id 05. IP address 192.168.000.002
What and where do I need to enter this info
I've gone back into the adagio composer and made the idoc ipid 05 as it originally said ip id 03 here then what should I do next?
Thanks to anybody that can point me in the right direction
toggle quoted message
Show quoted text
--- In Crestron@..., "jimathome80@..." <jimathome80@...> wrote:
I've not managed to set IP address yet. I have serial to rj11 cable from pc to idoc and then using view port select the same connection that I originally used to find IP address of aads then I run the wizard but the next screen shows a yellow dot next to idoc saying that's its not discovered! Could the com port setting have changed on my pc?
--- In Crestron@..., Phil Bridges <gravityhammer@> wrote:
Have you set an IP address in the iDoc? IIRC, you have to do that manually
using the supplied serial cable.
On Sat, Apr 27, 2013 at 9:22 AM, jimathome80@ <
jimathome80@> wrote:
**
Hi
Can anyone help?
I'm trying to setup a simple system of an 1 x aads 1 x tps4l and 1 x idoc
in adagio composer/system builder.
The problem I'm having is I'm unable to see the idoc when I use the device
discovery wizard. I've set up ip communications between the aads and then
crestnet commutation with the tps4l on an I'd of 03 but it asks for the
serial number of idoc?
All equipment is connected to my router what am I missing or doing wrong.
Sorry in advance for the basic question...
[Non-text portions of this message have been removed]
|
Re: Certification Changes
I hope the test is different because that would be complete BS if it was the same test. A guy I work with that has not been to the 3rd class called crestron and was offered a copy of the test and got it. It was the same test I had. WTF? You mean you are giving out the test to anyone now without the time constraints the rest of us had. That really doesn't sound fair.
toggle quoted message
Show quoted text
--- In Crestron@..., "doug_h_encinitas" <dghardy@...> wrote:
I just finished 301 last week and on Friday the sent out an email saying they were changing the cert test. I got mine in an email yesterday. And looks and sounds like the old cert test. Even one of the questions I remember someone telling me last week about needing to use a 8 or 12 digit keypad with .wav playback function and sure enough it was this cert. if u want I can shoot u a copy of the scope, I don't think it will hurt to see what ur getting into.
--- In Crestron@..., "Mark" <dedicatedsystems@> wrote:
I am in my C301 class this week.
Seems they are changing the test process? Anyone know the details?
Apparently a email went out this morning to crestron employees that they are changing the test.....
Anyone know?
|
Re: Discovery of idoc issue.
I've not managed to set IP address yet. I have serial to rj11 cable from pc to idoc and then using view port select the same connection that I originally used to find IP address of aads then I run the wizard but the next screen shows a yellow dot next to idoc saying that's its not discovered! Could the com port setting have changed on my pc?
toggle quoted message
Show quoted text
--- In Crestron@..., Phil Bridges <gravityhammer@...> wrote:
Have you set an IP address in the iDoc? IIRC, you have to do that manually
using the supplied serial cable.
On Sat, Apr 27, 2013 at 9:22 AM, jimathome80@... <
jimathome80@...> wrote:
**
Hi
Can anyone help?
I'm trying to setup a simple system of an 1 x aads 1 x tps4l and 1 x idoc
in adagio composer/system builder.
The problem I'm having is I'm unable to see the idoc when I use the device
discovery wizard. I've set up ip communications between the aads and then
crestnet commutation with the tps4l on an I'd of 03 but it asks for the
serial number of idoc?
All equipment is connected to my router what am I missing or doing wrong.
Sorry in advance for the basic question...
[Non-text portions of this message have been removed]
|
Re: Discovery of idoc issue.
Have you set an IP address in the iDoc? IIRC, you have to do that manually using the supplied serial cable. On Sat, Apr 27, 2013 at 9:22 AM, jimathome80@... < jimathome80@...> wrote: **
Hi
Can anyone help?
I'm trying to setup a simple system of an 1 x aads 1 x tps4l and 1 x idoc
in adagio composer/system builder.
The problem I'm having is I'm unable to see the idoc when I use the device
discovery wizard. I've set up ip communications between the aads and then
crestnet commutation with the tps4l on an I'd of 03 but it asks for the
serial number of idoc?
All equipment is connected to my router what am I missing or doing wrong.
Sorry in advance for the basic question...
[Non-text portions of this message have been removed]
|
Hi
Can anyone help?
I'm trying to setup a simple system of an 1 x aads 1 x tps4l and 1 x idoc in adagio composer/system builder.
The problem I'm having is I'm unable to see the idoc when I use the device discovery wizard. I've set up ip communications between the aads and then crestnet commutation with the tps4l on an I'd of 03 but it asks for the serial number of idoc?
All equipment is connected to my router what am I missing or doing wrong.
Sorry in advance for the basic question...
|
Simpl Windows watch not bolding- is it just me?
Just noticed tonight that with the most recent build of Simpl, when I set a watch on signals, the font is changing slightly, but not bolding like I'm used to seeing. Can't tell the difference between watched signals or not. I've just recently switched to running Macs for both my workstation and field laptop, so running Simpl in win7 via Parallels. I'm seeing this on both machines, and never noticed this before the latest update, but O am still getting used to the oddities of the Mac...
Is anyone else seeing this on standard PC's with this build or is it a known Mac thing? If it is a known Mac thing, does anybody know a solution? Very annoying when trying to validate code.
Thanks,
-cdr
|
