[bg305]

Originally Posted by Nine8Six

Read all, quoted the key message and understand fully what you are saying. And you are 100% correct. Main challenge being that cross-platform impediment and management from a coding perspective; Steve got an iPhone, Ruth got an Android, lil sister got an HTC, big sister got the new XYZ and cousin have his Blackberry, you see where I'm going with this...

Absolutely.. admittedly I have a software bias and see design challenges through that lens. My choice here would probably be WebBluetooth in a PWA app. It is then 1 application for most platforms. But that said, I acknowledge the overhead and while I would not mind throwing down the code myself it would require maintenance and patching, 2 years from now x api is no longer supported and the reality is hobby time is hard to come by. Now if it were something that had a wide audience and was no longer a hobby, that is different :P. All joking aside though I think sort of scope creep is what i feared in general with the screen and touch. I am curious to see what the possibilities are too (and open to them) but unless it is something really killer, I think I am personally more inclined to go with the simple buttons that don't have me taking apart half my interior to run wire to the screen. Ironically I used to rip brand new cars apart and stuff them full of screens, computers, cameras and all sorts of **************** and now I want them as close to original as possible.. Sorry, digression

Originally Posted by Nine8Six

Sought of using a cross-platform one-fit-all solution e.g. a browser addy http://xxx.xxx.xxx.xx:XXXX and port over lets say a NRF24L01+ or a LT8920 radio IC (2.4Ghz) but then the work involved is equivalent if not more than simply coding an X&Y axis touch screen. The radio would also require FCC ID (if compliance is an issue for anyone) :/

Yes.. when it comes to hardware i live blissfully in the naive prototype playground, buying controllers with approved radios, etc. That said I am following this thread with great interest because I want to understand the process better. Thank you for providing all the detail you do. When I get a few breathers over the next couple of weeks I am going to try to dig more into the details

Originally Posted by Nine8Six

Finally, if the device would be used daily like a tune-in radio or similar then it would make sense to put in connectivity but in this case chances the color & brightness settings will be set once (or twice) then forgotten.

I agree, but I think the other factor is how integrated it is and accessible. I think an android auto / apple car play head unit app that let you manage all interior led colors would likely get a lot of use. For all I know they are already available.

Originally Posted by Nine8Six

Not all lost cause. We'll have extra GPIOs on the device and probably use a nice quad size for developers to expand this controller to what-ever-they-want. That would include connectivity if what they add in the future requires that feature!!!

If there is anything that could convince me otherwise please do let me know and I'll reconsider my opinions. Thanks for trying to help out, appreciated btw!


Edit: Adding in a MCP2021A-330E/SN, sort of a gift to our Devs who wish to have both read & write access to the ECU and car data and/or build their own HMI around that (comm via k-line over 10400baud). So see, plenty of other tricks you'll be able to do with this lil cool box

Cool.. looks like a basic serial connection, could actually send that to a BT module if i got the inclination (or just solder up to a Arduino's serial for simplicity) and got board and wanted to create such an app . thank you!

BTW.. what type of messages would I want to send over the connection to the controller?? (Sorry if you have not gotten this far yet or if you posted it already)