REDCODE D Packet

[Gavin Greenwalt]

Is the REDCODE D Packet formatted correctly, it's lacking a prefix? Also there is a space in the prefix.

I'm getting something like this:

#$DRAGON:D:REDCODE:1|8|200|2200|100|100|0|| \\: 1|:

But shouldn't it be something like this:

#$DRAGON:D:REDCODE:1|8|200|2200|100|100|0|&redrc;|\\:1|:

 

[Trent Lillehaugen]

If you look at the REDCODE spinner (which uses the list) on the camera you will notice that it doesn't have the RC prefix and has spaces around the colon. This is different than the current display string (which is shown on the top) which has the RC prefix and no spaces around the colon.

I admit it's strange that our list items and current value string have a different format in this case, but it shouldn't cause any problems.

Are you running into a particular problem or just confused by the difference?

 

[Gavin Greenwalt]

I was just hoping to avoid a one-off programming condition in the UI to handle one oddball format. But I see now that you're right, the list isn't the same as the menu. It does seem a bit odd. Even ISO spells out ISO for every menu item. I'll leave in my conditional statement that watches for REDCODE packets and treats them slightly differently.

 

[Trent Lillehaugen]

I was just hoping to avoid a one-off programming condition in the UI to handle one oddball format. But I see now that you're right, the list isn't the same as the menu. It does seem a bit odd. Even ISO spells out ISO for every menu item. I'll leave in my conditional statement that watches for REDCODE packets and treats them slightly differently.

I don't like the idea of one-off programming conditions either - and we'll likely break your code if we decide to "fix" this problem down the line. I know that I sound like a broken record but it really would be worth your effort getting the API to work under windows phone (If I recall correctly). The API handles these things for you - or atleast abrstracts it so you don't care. We don't have any special handling code like this in any of our products that use the API (REDMOTE, iPad App, Android App, Switchblade, Camera UI, etc).

 

[Nick Morrison]

I love threads I can't understand, because I'm reminded there are people out there on a whole OTHER LEVEL.

Love this!

 

[Gavin Greenwalt]

I don't like the idea of one-off programming conditions either - and we'll likely break your code if we decide to "fix" this problem down the line. I know that I sound like a broken record but it really would be worth your effort getting the API to work under windows phone (If I recall correctly). The API handles these things for you - or atleast abrstracts it so you don't care. We don't have any special handling code like this in any of our products that use the API (REDMOTE, iPad App, Android App, Switchblade, Camera UI, etc).

Well, I would have to add this one-off code one way or another since I want the RC in my selection menu for consistency either way. And my personal SDK already has some tricks up its sleeve that the official one can't do yet (easy multi-cam support). Even if I do end up using the REDLink official SDK I think rebuilding it from scratch from a clean slate will let me offer a perspective that I wouldn't otherwise on ways it could be improved.

 

[Gavin Greenwalt]

For instance I just noticed there is not STARGET for sensor target. And as a result the framerate will just be dropped but never re-raised once you drop the resolution again. Not sure if it's desirable but... maybe. Wouldn't have noticed that if I wasn't working on the min/max target values.