Stalled Iris 16 - RGB Vandal Button

[rokabeka]

well, serial and usb lcd panels have been there for ages.
linux has a 'common' driver to them. I am thinking about writing my own, if we get there. it should eat only negligible amount of CPU cycles.
it does not necessarily need to be real-time, e.g. if it takes 1-2 s to reprogram then you can e.g. configure ranges or thresholds of temperature and Iris can change its color with a bit of a delay. that could still be a pretty awesome feature from a button
and if by clicking you could change between the cpu/hdd/gpu... or just simply assign a few LEDs per device and change their color independently (e.g. every segment had a temperature-dependent color transition from cold to hot like this: darkblue-lightblue-darkgreen-lightgreen-yellow-orange-red). endless possibilities.

I am in love with Iris

 

[iFreilicht]

I can't wait having the prototype! I know I am in the hat where you will pull some to deliver the first versions of Iris and that is awesome

I have some questions tho. as of now to me it looks like the patterns can be pre-programmed.
1.) how much time does it take to program the controller and start the new pattern?
2.) is it possible to run the LEDs with the previous program during re-programming?

to my usage I would like to display "real time" data on the LEDs. so maybe the most fluent solution for me would be driving the LEDs from the CPU directly. Do you think it could be possible? like keeping the USB interface but adding kind of a 'direct-drive' mode to the controller where e.g. a daemon running on the host controls the LEDs. changing between the modes by just clicking would be heaven itself

Not a secret, Iris would be kind of a network monitoring magic eye here.

Sorry if these ideas are already discussed, I might have missed them.

To answer the questions directly:

1.) how much time does it take to program the controller and start the new pattern?

If we're talking about loading a new configuration file onto the Iris, I don't know yet. I have not implemented the mass storage endpoint right now and I need to devise a robust protocol that allows different versions of the visualizer and firmware to be compatible. I'd say not more than a few seconds.

2.) is it possible to run the LEDs with the previous program during re-programming?

It might be, but I wouldn't count on it.

To give a practical answer to your questions:

In your position, I wouldn't use the programming function of the Iris at all. One endpoint of the Iris will be a serial link, just like all Arduinos have one. That's what you'll want to utilise.

In theory, there are draw_led(color) methods available that will allow you to draw a colour to any of the 12 LEDs directly. And if you've tried out the Iris visualizer, you've made yourself familiar with the concepts of Cues and Schedules. Those could be modified in real-time as well, so you can just change the colour of a running animation if you want or switch between animations. All of this is only implemented on the Iris itself right now, so these changes cannot be made via the serial link directly, but it could certainly be done.

Ideally, I would write a small python library that you can use to change all of these parameters on the Iris directly. Then you can do 100% of the logic on your PC. Or, If all of these functions are exposed on the serial link, you could just use any old serial library in your favourite language to talk to the iris.

But I cannot guarantee that I will have the time to implement either of those things, so here's what I can guarantee to work: If you get the firmware of the Iris 16 from Github and install the Arduino IDE, you will be able to modify the firmware. That way, you can implement some simple protocol for communication, so the PC could send something like "T1:50" over the serial connection and the Iris would interpret that as "temperature of sensor 1 is now 50°". How this changes the animation on the Iris can then be implemented in the firmware, but the important thing is that it would be an almost instantaneous change.

I hope that makes sense. If you need any sort of clarification, please ask!

Tbh, I really like that idea. But couldn't you run it over USB? I'm not sure how much latency that adds.

Even if the rendering logic runs on the PC, there's absolutely nothing to worry about in terms of bandwidth. Even at 130 FPS, you'd only have to send 12 commands to change the colour of each LED per frame. That's 3*12 = 36 bytes, plus a message header. This easily fits into a single 64 byte USB message, of which hundreds can be send each second.

Do you think you'd be able make it monitlr the temperature of the CPU or GPU.

Sure, but why would I? The only way to do this on the Iris directly is to use physical temperature sensors and read those out with the GPIOs. It makes much more sense to use a tool on the PC to read out the internal temperature sensors and then send commands to the Iris on how to change the animation.

well, serial and usb lcd panels have been there for ages.
linux has a 'common' driver to them. I am thinking about writing my own, if we get there. it should eat only negligible amount of CPU cycles.
it does not necessarily need to be real-time, e.g. if it takes 1-2 s to reprogram then you can e.g. configure ranges or thresholds of temperature and Iris can change its color with a bit of a delay. that could still be a pretty awesome feature from a button
and if by clicking you could change between the cpu/hdd/gpu... or just simply assign a few LEDs per device and change their color independently (e.g. every segment had a temperature-dependent color transition from cold to hot like this: darkblue-lightblue-darkgreen-lightgreen-yellow-orange-red). endless possibilities.

I am in love with Iris

The common serial driver should work perfectly fine as far as I am aware. Everything you describe would easily be doable the way I described it above Thanks for the compliment!

 

[HeroXLazer]

To answer the questions directly:



If we're talking about loading a new configuration file onto the Iris, I don't know yet. I have not implemented the mass storage endpoint right now and I need to devise a robust protocol that allows different versions of the visualizer and firmware to be compatible. I'd say not more than a few seconds.



It might be, but I wouldn't count on it.

To give a practical answer to your questions:

In your position, I wouldn't use the programming function of the Iris at all. One endpoint of the Iris will be a serial link, just like all Arduinos have one. That's what you'll want to utilise.

In theory, there are draw_led(color) methods available that will allow you to draw a colour to any of the 12 LEDs directly. And if you've tried out the Iris visualizer, you've made yourself familiar with the concepts of Cues and Schedules. Those could be modified in real-time as well, so you can just change the colour of a running animation if you want or switch between animations. All of this is only implemented on the Iris itself right now, so these changes cannot be made via the serial link directly, but it could certainly be done.

Ideally, I would write a small python library that you can use to change all of these parameters on the Iris directly. Then you can do 100% of the logic on your PC. Or, If all of these functions are exposed on the serial link, you could just use any old serial library in your favourite language to talk to the iris.

But I cannot guarantee that I will have the time to implement either of those things, so here's what I can guarantee to work: If you get the firmware of the Iris 16 from Github and install the Arduino IDE, you will be able to modify the firmware. That way, you can implement some simple protocol for communication, so the PC could send something like "T1:50" over the serial connection and the Iris would interpret that as "temperature of sensor 1 is now 50°". How this changes the animation on the Iris can then be implemented in the firmware, but the important thing is that it would be an almost instantaneous change.

I hope that makes sense. If you need any sort of clarification, please ask!



Even if the rendering logic runs on the PC, there's absolutely nothing to worry about in terms of bandwidth. Even at 130 FPS, you'd only have to send 12 commands to change the colour of each LED per frame. That's 3*12 = 36 bytes, plus a message header. This easily fits into a single 64 byte USB message, of which hundreds can be send each second.



Sure, but why would I? The only way to do this on the Iris directly is to use physical temperature sensors and read those out with the GPIOs. It makes much more sense to use a tool on the PC to read out the internal temperature sensors and then send commands to the Iris on how to change the animation.



The common serial driver should work perfectly fine as far as I am aware. Everything you describe would easily be doable the way I described it above Thanks for the compliment!

That's kind of what I meant... I need to learn to explain more.

 

[rokabeka]

thank you for the reply.
using a python lib makes it portable, I just have never written a single line of code in python. looks like I will need to start.
now I am really excited.
can't wait to start developing on Iris16 I love the idea of serial port but apparently it slowly vanishes from the motherboards (I am not worried, my AsrockRack EPC612D4I and x99 extreme4 both have it) but that is why I was rather thinking about USB.

are you planning to release a developers guide right at the time of delivering the prototypes?
if not, then I am willing to sign an NDA with you in order to get some insights or I am interested in any solution.

 

[iFreilicht]

using a python lib makes it portable, I just have never written a single line of code in python. looks like I will need to start.

Well you can also use any other programming language if you want to, but python is well suited for stuff like this.

I love the idea of serial port but apparently it slowly vanishes from the motherboards (I am not worried, my AsrockRack EPC612D4I and x99 extreme4 both have it) but that is why I was rather thinking about USB.

This is a misunderstanding! Yes the Iris 16 will be connected via USB, at all times! What I was talking about was a virtual serial port. All this means is that you can use a program like puTTY or a software library like pySerial or even just the Arduino Serial Monitor to send commands and data directly to Iris. It does NOT mean that you need a physical serial port on your mainboard!

So, when you connect the Iris 16 to your PC, it will show up as both a Mass Storage device and a CDC Virtual Serial Port. This means that you can drag-and-drop a configuration file onto it or send commands/data directly.

In python, that might look something like this:

>>> import serial
ser = serial.Serial('/dev/ttyUSB0')  # open serial port, on windows it's 'COM0'
print(ser.name)                      # check which port was really used
ser.write(b'ShowRedRing')            # write a string
ser.close()                           # close port

This will send the command "ShowRedRing" to the Iris 16. On there, you'd have already written something like this:

input = Serial.read();
if (input == "ShowRedRing"){
    draw_cue(red_ring);
}

So the Iris would interpret the incoming command and react accordingly.

are you planning to release a developers guide right at the time of delivering the prototypes?
if not, then I am willing to sign an NDA with you in order to get some insights or I am interested in any solution.

Hm I could certainly release a bit of well-documented example code. A full-on developer guide is not planned yet, but it might indeed be quite useful. We'll have to see.

now I am really excited.
can't wait to start developing on Iris16

I'd highly recommend you buy an Arduino starter kit and experiment a bit. Try to turn LEDs on and off, then do it via the Serial Monitor, then see if you can write your own piece of software in python that does that for you, maybe even by reading out temperature sensors of the CPU and GPU.

If you do all of those things now, you'll have a good understanding of the matter and it will be very easy to do the same on the Iris. If you only start once you get it, you'll probably get frustrated quickly. It's like learning to paint. If you start drawing with pencils on post-it notes and do it a lot until you learn how to transfer your thoughts onto the paper, you'll have a good basic set of skills to build upon when starting to draw oil on canvas.

Seriously, a big goal is reached in small steps. The earlier you start, the easier it will be

 

[rokabeka]

this all sounds cool. thanks for the advices.

 

[Biowarejak]

I'd highly recommend you buy an Arduino starter kit and experiment a bit. Try to turn LEDs on and off, then do it via the Serial Monitor, then see if you can write your own piece of software in python that does that for you, maybe even by reading out temperature sensors of the CPU and GPU.

Excellent advice to anyone wanting to work with a project like this

 

[fminus]

Since space is limited inside the switch, would it be more efficient to replace the push button switch with a capacitive touch one?

I apologize if this is a silly question.

 

[Biowarejak]

Since space is limited inside the switch, would it be more efficient to replace the push button switch with a capacitive touch one?

I apologize if this is a silly question.

That would actually be pretty neat and help differentiate the product while possibly also making it mechanically simpler to manufacture.

But I'd still want some kind of feedback, be it a rumble-motor or a tiny bit of audio.

 

[rokabeka]

But I'd still want some kind of feedback, be it a rumble-motor or a tiny bit of audio.

what about a small electric shock? both the motor and the speaker should be an additional device I think but wiring raw power to the switch is for free.
there can be a pattern when you touch the button it flashes for half a second or so. but that maybe would reduce the amount of memory could be used for programming.

 

[Biowarejak]

what about a small electric shock? both the motor and the speaker should be an additional device I think but wiring raw power to the switch is for free.
there can be a pattern when you touch the button it flashes for half a second or so. but that maybe would reduce the amount of memory could be used for programming.

True, forgot about the whole "lights turning on" thing I'm not sure how small either form of feedback i mentioned can get, but they would add complexity to be sure.

 

[EdZ]

A Piezo actuator bonded to the backside is the usual method to give 'tactile' feedback to a capacitive button. Some are now using LRAs for feedback on touchscreens more complex than a 'press'.

However, capacitive buttons are not CoTS parts like normal tac switches are (the major draw of capacitive sensing is to be able to integrate it into custom designs). Adding one would means designing one from scratch for manufacture.

 

[iFreilicht]

Since space is limited inside the switch, would it be more efficient to replace the push button switch with a capacitive touch one?

I apologize if this is a silly question.

@EdZ outlined it pretty well. It would be a somewhat complicated addition to make, but I can certainly see the appeal. The LEDs need to be offset back into the case a little anyway to make the illumination look good, so I doubt it would save much space. At this point I think the button has a good size anyway, I wouldn't want to make it any shorter.

But, thinking visionary: Why not both? This would be a very interesting option to the two-stage switches that were suggested earlier. So you'd be able to touch the button and do stuff that way and click it as well. The risk for accidental depression of the switch would be much lower.

That would actually be pretty neat and help differentiate the product while possibly also making it mechanically simpler to manufacture.

But I'd still want some kind of feedback, be it a rumble-motor or a tiny bit of audio.

Yeah mechanically it makes a bit of difference, could reduce the part count by one or two.

I'd do feedback visually rather than tactile, seems like a more obvious and way simpler solution.

what about a small electric shock? both the motor and the speaker should be an additional device I think but wiring raw power to the switch is for free.
there can be a pattern when you touch the button it flashes for half a second or so. but that maybe would reduce the amount of memory could be used for programming.

This switch is running on 5V, you're not gonna get shocked by that. And a transformer to increase that to a few hundred volts would take up an awful lot of space, not to mention that you're then pretty much generating ESD pulses inside your PC.

But yeah, just having one animation execute when the button is touched would absolutely work and I'd even like to do that with the regular switch as it is right now. It would indeed take up a little bit of space, but not more than any other animation.

 

[jeshikat]

what about a small electric shock? both the motor and the speaker should be an additional device I think but wiring raw power to the switch is for free.

Plasma speaker?

 

[iFreilicht]

Plasma speaker?

EZ PZ

 

[SkudShark]

Late to the game here but definitely would love to scoop one of these up, especially if I can enable it to Aura sync in a sort of dumb mode to just color change with the rest of my case lights.

 

[iFreilicht]

I wrote this update three weeks ago, but forgot to actually post it. Sorry, guys.

Just to keep you all in the loop:

I spent a lot of time trying to implement a virtual, simulated flash disk formatted with FAT16 on my Arduino, and while I got far enough to have windows recognise it as such, I did not manage to get it to actually mount, so no data could be read or written. After countless late nights spent on reading specifications for USB, LUFA, SCSI and FAT itself, I decided to give up on this plan for now and revisit it later on. I know it can be done, and it feels like it is close to completion, but I don't have the energy to pursue this right now, I need the project to move forward.

So the plan now is to integrate uploading a new configuration into the tool that I will write anyway for live communication with Iris. That's not an ideal solution, but it is good enough for now. The firmware part of this is implemented since today, so Cues and Schedules can be written and read as binary data through the virtual serial link.

Additionally, I integrated EEPROM, so the whole configuration will be stored in a dense byte format on there. Schedule rendering is done as well, and theoretically, arbitrary length schedules are possible. Practically, you will run out of RAM quickly, and if you want the schedule to persist after a restart, it needs to fit into the 1024 Byte small EEPROM anyway.

So, lots of progress, but nothing I can really show. I'll be on vacation for three weeks now, so don't expect any updates in that time. I will be online occasionally to answer potential questions, but nothing more.

Thanks for reading everybody!

Until the end of this month I'll be very busy finishing my bachelor's thesis, so don't expect too much progress either.

 

[FoskcoRS5]

Patiently waiting.

 

[iFreilicht]

Life gets in the way of things It's still on my radar, but I haven't been able to get more than one coherent hour a week into it at a time, so I'm moving enormously slow.

Even the forums I'm only visiting every two weeks or so at this point.

 

[Biowarejak]

I was wondering when you'd come back! I'm glad you're still working on this, at least when you can