Modules for Samsung displays?

jkranz286

Hello everyone.

What is the recommended method when there are no modules available for your specific display?

The Samsung displays that I will be controlling are:

Samsung UN85HU8550 - RS232

Samsung UN85JU7100F - RS232

Samsung UN49KU7000F - IR


Thank you for your input.

HARMAN_Lanussinio

You could use driver design in order to easily create your own module for the RS232 displays.
For the IR one just learn IR code from the remote or try a IR file for samsung screen on the amx website.

ericmedley

Honestly, I'd just write my own. In fact, I usually write my own. There are certain AMX written modules I use that have been vigorously vetted. But I've been burned many a time by manufacturers changing their protocol. And if I have to wait for AMX to get around to fixing the module I'm in big trouble. If a box stops working AMX doesn't get the phone call, I do. I'd much rather have the source code than hope and pray someone else gets to fixing it soon.

I feel it's very important for us as programmers to not get overly lazy in this regard. I feel like we should be able to everything AMX in house programmers can do if not more as we are out in the battle fields. If you discipline yourself early on to write your own modules you'll quickly build up a useful library that Yiu have full control over. I highly recommend Yiu follow the AMX standard SNAPI guidelines so that you or a future programmer can easily drop in a new module. In other words: don't make yiur modules so different that they cannot work with the current standards/best practices. Most my modules can plug right into any main code following the SNAPI standard.
just a thiught.

MLaletas

Samsung: I agree with Eric roll your own module, great learning experience and you get know to know all the ins and outs of the device. It's not too bad at all, it's actually one of my preferred protocols based on the information you can get from it (certainly better than sharps and panasonics). It's in hex but don't let that scare you, only small hard part is there is a checksum but you can build a small quick function to calculate that up for you

Coding: this is short rant triggered with what Eric said. Unlike other control platforms craptron notably. With amx you have to write damn near the entirety of the program on your own, as that should be the case. Craptron is so big that there are modules out there for every device, every function everything so it takes little skill to connect signals together and to get a program working. To me and this is especially true because I'm still trying to find a programmer to fill a vacant spot where I work, is that I hold much more value in an amx programmer than a craptron programmer. In order to program an amx system you need to have a greater skill set than the other. So because of that I tend to think really go to the extreme and make things custom and better than it would be with manufacturer modules.

Standards: Eric I am a little guilty of not fully complying to this..... oops. Most of my channels follow SNAPI, but all of my modules are built around my framework and are nonstandard. Although you could drop them in someone else's code and make it work it would just require a little preparation. Part of it is how I group them all together, initialize them, and have almost all the values in them be able to change dynamically. I guess in hindsight I could have done a better job in making it a little more standard but I am waaay to far in it now to do anything about. So to conclude basically I am sorry.

vining

While I've almost always written my own modules for the very reasons E mentioned it's not feasible for most companies with the ever changing product market. IMHO AMX and this community blew it's opportunity to make AMX a bigger success by not sharing more, opening the AMX modules where NDOs wouldn't be breached and dealers using the mode pedia forum as a repository for all their personal modules. It seems everyone had the mentatlity that their code had value that shouldn't be given freely to the compettition, fellow AMX dealers when in reality how many of us have ever bid against another AMX dealer? If you think about all the code that has been written that now sits in folders gathering dust just because most dealers gave up on AMX after AMX it seemed gave up on its dealers, it's a shame. If dealers shared more to help other dealers AMX could have been a more viable option for the collective community since a lot of companies can't afford to spend the time to write every module needed every time something changes. Now they sell other systems that rewuire less time, less commitment and their library of home rolled modules never sees the light of day.

ericmedley

MLaletas wrote: »

Samsung: I agree with Eric roll your own module, great learning experience and you get know to know all the ins and outs of the device. It's not too bad at all, it's actually one of my preferred protocols based on the information you can get from it (certainly better than sharps and panasonics). It's in hex but don't let that scare you, only small hard part is there is a checksum but you can build a small quick function to calculate that up for you

Coding: this is short rant triggered with what Eric said. Unlike other control platforms craptron notably. With amx you have to write damn near the entirety of the program on your own, as that should be the case. Craptron is so big that there are modules out there for every device, every function everything so it takes little skill to connect signals together and to get a program working. To me and this is especially true because I'm still trying to find a programmer to fill a vacant spot where I work, is that I hold much more value in an amx programmer than a craptron programmer. In order to program an amx system you need to have a greater skill set than the other. So because of that I tend to think really go to the extreme and make things custom and better than it would be with manufacturer modules.

Standards: Eric I am a little guilty of not fully complying to this..... oops. Most of my channels follow SNAPI, but all of my modules are built around my framework and are nonstandard. Although you could drop them in someone else's code and make it work it would just require a little preparation. Part of it is how I group them all together, initialize them, and have almost all the values in them be able to change dynamically. I guess in hindsight I could have done a better job in making it a little more standard but I am waaay to far in it now to do anything about. So to conclude basically I am sorry.

I wouldn't feel bad about not always following SNAPI. It doesn't work for everything. In fact all my medial server modules don't even come close as SNAPI (IMHO) is not built for it. There are obviously many things we deal with that don't fit that mold. But for yiur workaday things like source or end point devices it's a perfectly fine convention. I'm not a fn of the few cases where they combine feedback channels with action channels like int the case of audio mute - channel 199. But for the most part it's okay.

to Vining's point - I tend to agree with some slight reservation. The whole notion of open source I tend to be more skeptical on the fairness of my fellow man. As proof of this I can site the Open-Source and free cost of LINUX, a platform I personally use and prefer. By almost any metric it is a better OS than Windows no Mac. But it has not caught on en masse'. Why? Tons of reasons. As most of us long-timers here on the forum may remember we had a bad spell of non-professional trolls allowed on basically asking us to write code for them for free because it was beneath their dignity to actually get the training and experience we spent countless hours and blood, sweat and tears getting. AND if we dared bring this fact up, we were then branded backward-thinking f$ck's who didn't understand open-source.

i thin Vining hit the nail on the head with AMX modules. The biggest complaint with them was reliability. I think we programmers were not without understanding and empathy for the plight of the folks writing the modules. We all have written code that "mostly" worked but had the occasional bug. Or even more commonly the manufacturer just up and changed the protocol. If we had a space here in the forum limited to the group with NDO s or whatnot with Source for the modules, we could have reacted quickly to the changes. Or even better yet - a community of programmers with a GIT or SVN repo with AMX management of the trunks to track public vs. private versions of the modules and their revisions. One of us VIPs could have managed it without any AMX Employees spending time on it.

i dunno... Woulda - Ciulda - Shoulda...

vining

ericmedley wrote: »

i dunno... Woulda - Ciulda - Shoulda...

Yeah it's a little late now. That ship didn't just sail, it sunk! Now if AMX had 5 full time programmers taking on the tasks of from IR data base maintenance to new modules for the new devices that are widely used. Paid those guys $100k/yr which IMHO would be pretty decent pay then AMX would have roughly a $600k year expense w/ bennies. Now if those 5 programmers were able to keep 100 dealers selling AMX products and those dealers average only $30k a year in sales that's $3m a year. Now lets think about how many dealers there used to be and could have been if there was more attention paid to taking care of dealer's needs. Even with the changing market place companies like C4 are doing extremely well and probably acquired a 1000 dealers in the US since the time AMX started its decline.

C4
Revenue for the fourth quarter of 2016 was $57.4 million, compared to revenue of $42.9 million for the fourth quarter of 2015, representing year-over-year growth of 34%. Total revenue for the twelve months ended December 31, 2016 grew 28% year-over-year, from $163.2 million to $208.8 million, or 15% on a pro forma basis, assuming the January 2016 acquisition of Pakedge Device & Software Inc. had occurred at the beginning of 2015.

Saying there's no market in resi was a mistake and just wait when C4 ventures more into the commercial domain. Not to mention the guys running these commercial entities are getting C4 installed in their home and if they like it in their homes which IMHO is a more complicated installation then they'd see it as a useful fit for their boardrooms and conference rooms.

sentry07

I just ran into similar models and those models of Samsung displays will most likely only have an EX-Link port on the back, so the usual $AA,$11... RS232 protocol for commercial displays won't work. There's a protocol specifically for Samsung EX-Link. A few commands to try:

Power On = "$08,$22,$00,$00,$00,$02,$D4"
Power Off = "$08,$22,$00,$00,$00,$01,$D5"
HDMI1 = "$08,$22,$0a,$00,$05,$00,$c7"

9600 baud. I have the rest in a document around here somewhere if you need them. I'd just put those commands in a button event or in your power on/off functions and be done with it. I don't think they provide polling feedback on the EXLink port, or at least I don't have any info on doing it.

ericmedley

vining wrote: »

Saying there's no market in resi was a mistake and just wait when C4 ventures more into the commercial domain. Not to mention the guys running these commercial entities are getting C4 installed in their home and if they like it in their homes which IMHO is a more complicated installation then they'd see it as a useful fit for their boardrooms and conference rooms.

I agree that it's more complicated. I'd suggest a better way to describe what happened was the market "Moved Away" from higher-end automation toward an environment of less customization. I think I tend to be a bit more forgiving of our industry than perhaps you do. I don't think we handled it well. but, I'm not sure there was a better way to handle it.

Also, I agree that our days are numbered in Commercial as well. I find myself wandering farther and farther afield in search of the dwindling waterholes of where folks like us tend to thrive: Highly customizeable systems. Things like board rooms, divisible a/v spaces and large scale a/v distribution are tending to settle into "known science" that is now possible to use a check-list style programming method. I myself have written a lot of code this way. It's just I'm still the person filling in the check boxes.

My main market is still those areas too big to be well serviced by the mindless machines generating code. I realize that one day I might not be able to make it to the next watering hole.