you know, there is a subform needed here at diyaudio: one for remote control systems! oh well, since we don't have one, this is the closest I can find
its my remote control for an analog preamp system (amb's and my own alpha10 relay r2r attenuator and i/o selector).
for a few years now, its been IR remote controlled, along with some front panels buttons. but now, I'm getting into xbee (and similar) packet radios for short distance control use and I have this, now working, as a proof of concept.
the control chip is an arduino (under the screen), screen is $10 oled display in white (will be behind a color plastic filter when its mounted in a box). not shown is the xbee, but those are all standard (it will be mounted behind this board).
still needs batteries and a case, but other than that it does work. you can move the volume in two speeds: up/down moves in 4db jumps (user settable) and left/right moves in small jumps (1db is what I have it set to). center button is mute. I have not decided what green and blue will do (lol).
this will be open source and posted to my github account once the code is cleaned up. you need a matching xbee and code on the 'other side', of course, but the control protocol will be open and its not hard to integrate this in other diy systems.
(wish we had a forum for 'control systems'. I think it would be a good idea, as more audio systems go on the IoT bandwagon...)
its my remote control for an analog preamp system (amb's and my own alpha10 relay r2r attenuator and i/o selector).
for a few years now, its been IR remote controlled, along with some front panels buttons. but now, I'm getting into xbee (and similar) packet radios for short distance control use and I have this, now working, as a proof of concept.
the control chip is an arduino (under the screen), screen is $10 oled display in white (will be behind a color plastic filter when its mounted in a box). not shown is the xbee, but those are all standard (it will be mounted behind this board).
still needs batteries and a case, but other than that it does work. you can move the volume in two speeds: up/down moves in 4db jumps (user settable) and left/right moves in small jumps (1db is what I have it set to). center button is mute. I have not decided what green and blue will do (lol).
this will be open source and posted to my github account once the code is cleaned up. you need a matching xbee and code on the 'other side', of course, but the control protocol will be open and its not hard to integrate this in other diy systems.
(wish we had a forum for 'control systems'. I think it would be a good idea, as more audio systems go on the IoT bandwagon...)
absolutely! here's my 'led-duino' (not the real name, though) version:
you can see the xbee on the perf board front user-interface panel. I'm using a standard arduino nano with onboard usb, a rotary encoder and a trio of pcb mount square buttons. its still based on the volumaster code base and can run just the same on the lcduino with some software changes. none of the UI changes I made need to be done, but the xbee needs to be connected to the uart on the arduino and it needs 5v.
I also have an IR 'gateway' that works; it can learn the codes the lcduino can, but it emits the corresponding xbee serial message - which is what I now prefer as the remote control system for multi-box and bi-directional control. so, with an IR remote, you can use the arrow keys (etc) and it will send out relative vol adjustments (go up 1, go down 4, etc). but the protocol I put together for the xbee supports absolute, as well, so you can go directly to any dB value without stepping. this handheld oled remote could send both but it happens to send absolute style vol change messages.
btw, here's my test bed, primitive as it may be:
using a canon junker digicam battery. will figure out a better power supply later 😉
its not an end solution, but its a good enough software devel test bed, at least. and it does really work, so its cool to iterate thru the software changes and see immediate results. still lots more to code, and more equipment to be able to control.
just got this done tonite.
you can see the xbee on the perf board front user-interface panel. I'm using a standard arduino nano with onboard usb, a rotary encoder and a trio of pcb mount square buttons. its still based on the volumaster code base and can run just the same on the lcduino with some software changes. none of the UI changes I made need to be done, but the xbee needs to be connected to the uart on the arduino and it needs 5v.
I also have an IR 'gateway' that works; it can learn the codes the lcduino can, but it emits the corresponding xbee serial message - which is what I now prefer as the remote control system for multi-box and bi-directional control. so, with an IR remote, you can use the arrow keys (etc) and it will send out relative vol adjustments (go up 1, go down 4, etc). but the protocol I put together for the xbee supports absolute, as well, so you can go directly to any dB value without stepping. this handheld oled remote could send both but it happens to send absolute style vol change messages.
btw, here's my test bed, primitive as it may be:
using a canon junker digicam battery. will figure out a better power supply later 😉
its not an end solution, but its a good enough software devel test bed, at least. and it does really work, so its cool to iterate thru the software changes and see immediate results. still lots more to code, and more equipment to be able to control.
just got this done tonite.
Just a thought, for those like me with a wife and kids that like to hide the remote.
Add a small speaker on the remote and a button on the front of the LCDuino to call it.
Will it also have IR to control a CDP or are you planning on just preamp controller?
The little display on the remote and on the preamp look nice!
Does the code fore the new preamp display take up any less space to free up memory to add features the the LCDuino? If I understand correct, the LCDuino is about maxed out for program size right now?
Add a small speaker on the remote and a button on the front of the LCDuino to call it.
Will it also have IR to control a CDP or are you planning on just preamp controller?
The little display on the remote and on the preamp look nice!
Does the code fore the new preamp display take up any less space to free up memory to add features the the LCDuino? If I understand correct, the LCDuino is about maxed out for program size right now?
the 'find me' feature is a good idea and I did plan to have a small piezo spkr in there.
I have 2 plans for the spkr; it can be driven by very simple tones (from the arduino tone library) or you can get wavelet clip playback, by index number, from a dedicated dip-like module (that is under $10). that will be more for a desk-style remote or controller; and for the handheld, since space and weight matters, the 'free' version that uses pwm waves in the controller is enough.
one of the screens or pages in the remote will be for timers and alarms and so a noise source is needed for that, as well.
but I'll add the 'find me' feature to the list. thanks 😉
(in fact, I'm thinking of how it will all be managed, with device addresses and auto-config like dhcp is for ip networks. its all being planned out).
as for IR, I have a solution that works for me and maybe its good enough for others. since I converted the preamp over from IR to xbee, I still found I wanted to use my lightweight and easy to replace sony IR remote. so I built a translator gateway that takes in the learned sony ir codes and sends out corresponding xbee messages.
if I didn't tell you there was this extra box, you would never know it was there 😉 you point your sony(etc) remote at that translator (tiny little box) and it blasts out the xbee rf, which of course is not line-of-sight limited anymore. you could have the translator box with you in some other room, use your ir remote and have the xbee messages go to the system in the far bedroom or living room.
finally, there is going to be a few other back-ends as interfaces. REST api's are all the hot thing these days and so I'll have a RESTful object tree that you can hit and do GETs and SETs on, to control the various gear in your system. that works at the JSON level and is a simple abstraction that other clients can talk to. there will also be some kind of simple web gui for when humans want to hit that webserver, instead of apps (the app might speak json/rest but the human wants html and images and gui elements).
all that is being worked on and prototyped.
as for the lcduino code space, its maxed out so some things would have to go, but not too much. there is quite a bit of stuff that does not fully earn its keep (a lot of the menu system, for example). if my system works as I hope, then the local menu system won't be needed since all config can then be done remotely. that frees up a ton of space and also simplifies the lcduino's job. you can swap out the IR for an xbee or just leave the IR there, but I think the way forward is all packet radio. its two-way, its addressible and its much more flexible than simple IR. IR is a transitional thing, but other forms should be used going forward (imho).
I have 2 plans for the spkr; it can be driven by very simple tones (from the arduino tone library) or you can get wavelet clip playback, by index number, from a dedicated dip-like module (that is under $10). that will be more for a desk-style remote or controller; and for the handheld, since space and weight matters, the 'free' version that uses pwm waves in the controller is enough.
one of the screens or pages in the remote will be for timers and alarms and so a noise source is needed for that, as well.
but I'll add the 'find me' feature to the list. thanks 😉
(in fact, I'm thinking of how it will all be managed, with device addresses and auto-config like dhcp is for ip networks. its all being planned out).
as for IR, I have a solution that works for me and maybe its good enough for others. since I converted the preamp over from IR to xbee, I still found I wanted to use my lightweight and easy to replace sony IR remote. so I built a translator gateway that takes in the learned sony ir codes and sends out corresponding xbee messages.
if I didn't tell you there was this extra box, you would never know it was there 😉 you point your sony(etc) remote at that translator (tiny little box) and it blasts out the xbee rf, which of course is not line-of-sight limited anymore. you could have the translator box with you in some other room, use your ir remote and have the xbee messages go to the system in the far bedroom or living room.
finally, there is going to be a few other back-ends as interfaces. REST api's are all the hot thing these days and so I'll have a RESTful object tree that you can hit and do GETs and SETs on, to control the various gear in your system. that works at the JSON level and is a simple abstraction that other clients can talk to. there will also be some kind of simple web gui for when humans want to hit that webserver, instead of apps (the app might speak json/rest but the human wants html and images and gui elements).
all that is being worked on and prototyped.
as for the lcduino code space, its maxed out so some things would have to go, but not too much. there is quite a bit of stuff that does not fully earn its keep (a lot of the menu system, for example). if my system works as I hope, then the local menu system won't be needed since all config can then be done remotely. that frees up a ton of space and also simplifies the lcduino's job. you can swap out the IR for an xbee or just leave the IR there, but I think the way forward is all packet radio. its two-way, its addressible and its much more flexible than simple IR. IR is a transitional thing, but other forms should be used going forward (imho).
oh, and you asked about cdp.
at first, I will attack the linux audio player I use, 'mpd'. I want to remotely control, at the basic and 95% level, simple song transport such as prev/next/pause/resume. I want to at least get the current song and maybe its current play time. I'm pretty sure all that is doable from mpd and that if I have an xbee on the same pc as my mpd system, it can be a proxy and take commands from the xbee remote peer.
I don't want a whole kitchen sink. I like having the most common things that you use all the time and not much more than that. so, simple volume control, simple transport control and some i/o selector control will be a good first POC of the multi-system control concept I'm shooting for.
at first, I will attack the linux audio player I use, 'mpd'. I want to remotely control, at the basic and 95% level, simple song transport such as prev/next/pause/resume. I want to at least get the current song and maybe its current play time. I'm pretty sure all that is doable from mpd and that if I have an xbee on the same pc as my mpd system, it can be a proxy and take commands from the xbee remote peer.
I don't want a whole kitchen sink. I like having the most common things that you use all the time and not much more than that. so, simple volume control, simple transport control and some i/o selector control will be a good first POC of the multi-system control concept I'm shooting for.
Well then, sounds like you have it under control. [emoji41]
Short and sweet as I don't want to divert the thread, but, do you see any prospects for more DIY friendly multi channel digital attenuator chips on the forefront? I hear the Cirrus can be a bit of a bugger but has outstanding specs?
I'm going with a fleabay stepped attenuator for now, on the way, but will eventually like to add the Duino and remote creature comforts.
Short and sweet as I don't want to divert the thread, but, do you see any prospects for more DIY friendly multi channel digital attenuator chips on the forefront? I hear the Cirrus can be a bit of a bugger but has outstanding specs?
I'm going with a fleabay stepped attenuator for now, on the way, but will eventually like to add the Duino and remote creature comforts.
here are 4 screens that I have partially implemented.
as you press the blue button, it cycles to the next page. the idea is that this will fetch the current value, show it and let you edit/change it and you can stay and hang out there or move on to the next thing to control/change.
first implementation will have lots of harcoded things, but should really be talking to discrete boxes. later on I plan to abstract it a bit more and make things dynamic and discoverable, to some degree.
also planning to add IR-send to the mix, on a remote separate little box of its own. it would be an ir blaster that listens for the right input xbee messages and sends out the 'right' IR blasts. I guess that would be one way to blindly control an old school cd player, at least for some IR commands. it would get you pause/prev/next kind of stuff, at least. no idea when I'll get to that but its do-able and I can see it being part of the whole system, as an optional addressible box of its own.
as you press the blue button, it cycles to the next page. the idea is that this will fetch the current value, show it and let you edit/change it and you can stay and hang out there or move on to the next thing to control/change.
first implementation will have lots of harcoded things, but should really be talking to discrete boxes. later on I plan to abstract it a bit more and make things dynamic and discoverable, to some degree.
also planning to add IR-send to the mix, on a remote separate little box of its own. it would be an ir blaster that listens for the right input xbee messages and sends out the 'right' IR blasts. I guess that would be one way to blindly control an old school cd player, at least for some IR commands. it would get you pause/prev/next kind of stuff, at least. no idea when I'll get to that but its do-able and I can see it being part of the whole system, as an optional addressible box of its own.
Attachments
more progress today: I bought some adafruit stuff and integrated it; one of their lipo batteries and one of their usb charger boards (top area of photo with the green 'charging done' light on):
battery is just stuck on the back with double stick tape, for now:
the power switch, at top, is there until I get hibernation fully working.
next, Qi charging! have to buy a charging base and integrate the receiving coil but hope to have that working by next update.
battery is just stuck on the back with double stick tape, for now:
the power switch, at top, is there until I get hibernation fully working.
next, Qi charging! have to buy a charging base and integrate the receiving coil but hope to have that working by next update.
Qi charging works! so far, at least:
green light on the charging board shows its down. otoh, the blue/red lights on the base show its still in-progress. we'll have to see how this works out and if its a good stable tech or just a fad. for now, though, I like the idea and will build a cradle and embed the receiver coil so that their alignment is guaranteed.
green light on the charging board shows its down. otoh, the blue/red lights on the base show its still in-progress. we'll have to see how this works out and if its a good stable tech or just a fad. for now, though, I like the idea and will build a cradle and embed the receiver coil so that their alignment is guaranteed.
all boxed up!
....and 'thick as a brick' LOL
but hey, its using all off-the-shelf parts and first version is not supposed to be anything other than a proof of concept (POC).
and for that, it does nicely. the qi charging works and I'm pretty happy with it, so far.
it controls my preamp but I'm now working on an mpd interface and hope to have playback control working in the next few days. that will meet my minimal needs; if I can use this remote to change volume at the preamp level and also play/pause/skip songs at the mpd level, I'll consider the goal to have been reached. (it will also control my spdif switch and some other devices, later on).
....and 'thick as a brick' LOL
but hey, its using all off-the-shelf parts and first version is not supposed to be anything other than a proof of concept (POC).
and for that, it does nicely. the qi charging works and I'm pretty happy with it, so far.
it controls my preamp but I'm now working on an mpd interface and hope to have playback control working in the next few days. that will meet my minimal needs; if I can use this remote to change volume at the preamp level and also play/pause/skip songs at the mpd level, I'll consider the goal to have been reached. (it will also control my spdif switch and some other devices, later on).
Looks neat up until chassis.😀all boxed up!
....and 'thick as a brick' LOL
but hey, its using all off-the-shelf parts and first version is not supposed to be anything other than a proof of concept (POC).
and for that, it does nicely. the qi charging works and I'm pretty happy with it, so far.
it controls my preamp but I'm now working on an mpd interface and hope to have playback control working in the next few days. that will meet my minimal needs; if I can use this remote to change volume at the preamp level and also play/pause/skip songs at the mpd level, I'll consider the goal to have been reached. (it will also control my spdif switch and some other devices, later on).
its definitely a brick 😉 but its a proto and I don't mind, personally.
it would be fun to get a 3d printed nice countoured case made, though! I have zero 3d printing skills. that might change, but right now, this is about as good as I (personally) can do. and even so, this took a full 6 hours at the laser cutter, doing and redoing layers until it finally all fit.
it would be fun to get a 3d printed nice countoured case made, though! I have zero 3d printing skills. that might change, but right now, this is about as good as I (personally) can do. and even so, this took a full 6 hours at the laser cutter, doing and redoing layers until it finally all fit.
I've been trying to think of how to put this into a nice enclosure since your first post. I'm drawing a blank as well. I can do all kinds of neat stuff with aluminum but that would be an even heavier brick when finished. 3D printing might be a possibility.
3d skills (drawing and machining) is a whole thing into itself and I'm not personally there, yet. but lots of people are. anyone out there want to join in the fun? 😉
for completeness, I might also add in an ir-sender port, but my focus is more about 2-way communications and that means radio (xbee for now, but I'm also looking into the cheaper packet radio modules, such as from nordic).
for completeness, I might also add in an ir-sender port, but my focus is more about 2-way communications and that means radio (xbee for now, but I'm also looking into the cheaper packet radio modules, such as from nordic).
I'm not ready to dive into bluetooth stuff quite yet. its a whole lot more complex than just simple serial over xbee and pairing was always a PITA unless both sides had a more meaningful display.
if some other device I had to talk with ONLY spoke bluetooth, that would be one thing, but since I control both sides I can pick any radio tech that makes sense.
what I'm thinking about to have a non-xbee choice is the nordic chips, the nRF24l01 (I think that's the item) and those are in the $5 range and would be a nice affordable alternative to the expensive xbees. they also take up much less room as well.
if some other device I had to talk with ONLY spoke bluetooth, that would be one thing, but since I control both sides I can pick any radio tech that makes sense.
what I'm thinking about to have a non-xbee choice is the nordic chips, the nRF24l01 (I think that's the item) and those are in the $5 range and would be a nice affordable alternative to the expensive xbees. they also take up much less room as well.
Linx does some neat affordable radios too. https://linxtechnologies.com/blog/humpro-wireless-data-transceiver-module-flexibility-at-a-low-cost/
cool, I'll look into that one, too.
I am not 100% sold on xbee. its a bit expensive, needs a custom socket (damned pin spacing!) and is not actually a reliable transport on its own, it needs a 'tcp like' thing on top of it, which is not very efficient (the radio itself should do that tcp stuff but it seems it does not).
otoh, xbee is very mature and stable tech, its pretty well supported and well understood and I like that it does have encryption built in (should you want it). there are also logical channels so you could configure things to be 'ships in the night' and not have to bump into each other or share the bandwidth (if one type of device needs more critical realtime data and the other on the network does not, they might be better off using separate 'channels' or pan-ids). you can segregate data nicely that way.
the nRF nordic modules are very cheap, though, and pretty easy to interface to in arduino. I have a pair of them but have not tried to use them yet. if I find they are as good (or even better) I may convert over to them.
additionally, there is the new hotness in IoT, the esp8266 module. here's a break-out board I made and you can see the wifi module hanging on the socket with its pcb antenna:
that little blue board is a full ip stack and can run arduino-like apps directly on it. its not fast, though, and its not a super stable chip (yet). it may be over time and so its worth watching. I've found that it takes seconds to get a tcp connect to a remote server and that's too long for remote control stuff (vol control, at least). but, it could be useful to deal with slower time order things, like config settings up/down load or fetching time from an ntp server or sending control messages to things that don't need a very fast control loop.
another possibility is to have the xbee (or radio inside the remote) know how to talk to a gateway xbee/esp8266 box. imagine that break-out board, above, but with an xbee on there as well. the remote could talk to the xbee on that board and that could proxy the request out to the ip network over wifi and then return the data back over xbee. this keeps the remote control code simple and uniform and yet you still have a way out to the ip network in case you want to control things that are really running ip.
I am not 100% sold on xbee. its a bit expensive, needs a custom socket (damned pin spacing!) and is not actually a reliable transport on its own, it needs a 'tcp like' thing on top of it, which is not very efficient (the radio itself should do that tcp stuff but it seems it does not).
otoh, xbee is very mature and stable tech, its pretty well supported and well understood and I like that it does have encryption built in (should you want it). there are also logical channels so you could configure things to be 'ships in the night' and not have to bump into each other or share the bandwidth (if one type of device needs more critical realtime data and the other on the network does not, they might be better off using separate 'channels' or pan-ids). you can segregate data nicely that way.
the nRF nordic modules are very cheap, though, and pretty easy to interface to in arduino. I have a pair of them but have not tried to use them yet. if I find they are as good (or even better) I may convert over to them.
additionally, there is the new hotness in IoT, the esp8266 module. here's a break-out board I made and you can see the wifi module hanging on the socket with its pcb antenna:
that little blue board is a full ip stack and can run arduino-like apps directly on it. its not fast, though, and its not a super stable chip (yet). it may be over time and so its worth watching. I've found that it takes seconds to get a tcp connect to a remote server and that's too long for remote control stuff (vol control, at least). but, it could be useful to deal with slower time order things, like config settings up/down load or fetching time from an ntp server or sending control messages to things that don't need a very fast control loop.
another possibility is to have the xbee (or radio inside the remote) know how to talk to a gateway xbee/esp8266 box. imagine that break-out board, above, but with an xbee on there as well. the remote could talk to the xbee on that board and that could proxy the request out to the ip network over wifi and then return the data back over xbee. this keeps the remote control code simple and uniform and yet you still have a way out to the ip network in case you want to control things that are really running ip.
- Status
- Not open for further replies.