Welcome! Log In Create A New Profile

Advanced

Using Pogoplug for a "Transceiver of all trades"

Posted by craigcoffman 
Using Pogoplug for a "Transceiver of all trades"
January 28, 2016 03:13PM
Ahh.. that makes more sense. Must've not pasted the command in correctly or something when I did it. After doing it a few times, it's easy to get careless I guess. Glad it was nothing to hard to fix.

Moderator: the sentence below is where we start the Using Pogoplug for a "Transceiver of all trades" thread

These things make great single-purpose print/scan or whatever servers. I use a couple for A/V rack IR control.



Edited 2 time(s). Last edit at 09/30/2016 05:06AM by bodhi.
Re: Pogo Plug Mobile - Constant Orange LED after succesful Debian install
January 28, 2016 03:30PM
craigcoffman Wrote:
-------------------------------------------------------
I use a couple for A/V rack
> IR control.


We need a write up! This would be excellent to add to bodhi's wiki
Re: Pogo Plug Mobile - Constant Orange LED after succesful Debian install
January 28, 2016 03:42PM
It's pretty straightforward.

here's the magic bit:

http://www.iguanaworks.net/ << the IR transmitter

& some info to get you started:

You definitely have to have a LIRC-capable machine with some sort of IR receiver on it as well to "record" the various IR codes you want to send. (I had previously built an old db9 serial IR receiver based on the schematic on the LIRC page & I used it for recording my codes)

Then you wire some IR emmitters to some old mini-din stereo cables (taping the emitters over the various devices IR receivers is the way to go). These plug into the Iguana device... definiely buy the one with the multiple outputs (you get two channels per mini-din)

Attached is a sample IR-code that I captured (for Denon receivers) & a PHP script (with HTML front) I wrote to provide a web-interface for the controls. This allows me to control the rack from my phone/tablet/PC
Attachments:
open | download - denon_rcvr_pwr.txt (644 bytes)
open | download - IRControl.html (6.1 KB)
open | download - IRControl.php (11.4 KB)
Re: Pogo Plug Mobile - Constant Orange LED after succesful Debian install
January 28, 2016 06:39PM
TEN
Re: Pogo Plug LIRC
September 28, 2016 04:22PM
craigcoffman Wrote:
-------------------------------------------------------
> here's the magic bit:
>
> http://www.iguanaworks.net/ << the IR
> transmitter
>
> & some info to get you started:
>
> You definitely have to have a LIRC-capable machine
> with some sort of IR receiver on it as well to
> "record" the various IR codes you want to send.

Shouldn't there be a way to use a remaining/accessible few of the ARM's many GPIOs instead (even for RF besides IR), like http://forum.doozan.com/read.php?3,21789,24676#msg-24676 (since bodhi did port the lirc_rpi module) ?
Re: Pogo Plug LIRC
September 28, 2016 07:10PM
I think TEN has this really good idea from the linked post. I've qoted here again to raise interests:

Quote

While taking Pogo E02s apart, have you had a chance to identify GPIO pins otherwise unused (i.e. not even for serial) on their board (no header needed if accessible at least as solder pads or pins) that might drive the Bodhi-ported lirc_rpi http://forum.doozan.com/read.php?2,20686,21168#msg-21168 for RF(-to-IR) remote control transceivers such as http://www.ebay.com/itm/201312653471 (cf. http://forum.doozan.com/read.php?8,21494,21494) ?

With their open base and collector respectively, these particular TX & RX modules (though the latter should better be replaced with a superhet) might even interface with 3,3V without putting the ARM's voltage tolerance in jeopardy (at the PSU's 5V or even up to 12V if it supplies these anywhere), cf. http://www.forum-raspberrypi.de/Thread-433mhz-funk-module-schaltplan.

Or is it even possible to (re-)program and repurpose the JTAG header as GPIO during normal operations?

The ability to use LIRC without a softcarrier and hence drive various radio transceivers might provide a good chance to control the bulk of household electronics (home entertainment, switchable sockets & lights, and conversion back to infrared in more distant locations) from within a Pogoplug, rather than added on a Pi (that better serves Kodi-like AV tasks).

I could help with the software part to expose them properly. But down to the board level soldering and electronics stuff, I'm not qualified :) perhaps Gravelrash and bobafetthotmail might want to chime in.

If you don't have access to the Hardware Specs and Functional Specs for the 6281 reference manual, please let me know.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner



Edited 1 time(s). Last edit at 09/28/2016 07:15PM by bodhi.
TEN
Re: Pogo Plug RF LIRC
September 29, 2016 02:06AM
bodhi Wrote:
-------------------------------------------------------
> I think TEN has this really good idea from the
> linked post. I've qoted here again to raise
> interests:
>
>
Quote

While taking Pogo E02s apart, have you had
> a chance to identify GPIO pins otherwise unused
> (i.e. not even for serial) on their board (no
> header needed if accessible at least as solder
> pads or pins) that might drive the Bodhi-ported
> lirc_rpi ... [433 MHz AM RF] TX & RX modules ...
> The ability to use LIRC without a softcarrier and
> hence drive various radio transceivers might
> provide a good chance to control the bulk of
> household electronics (home entertainment,
> switchable sockets & lights, and conversion back
> to infrared in more distant locations) from within
> a Pogoplug, rather than added on a Pi (that better
> serves Kodi-like AV tasks)
.
>
> I could help with the software part to expose them
> properly. But down to the board level soldering
> and electronics stuff, I'm not qualified :)
> perhaps Gravelrash and
> bobafetthotmail might want to chime in.

Thanks again for your support!

To my regret, travel requirements have kept me from getting further on the hardware side myself.

Handily since I first raised the idea though, the 2.4 GHz OQPSK Mi-Light protocol https://github.com/henryk/openmili (used under different names such as LightMe by various "DIY mart" LED bulbs as well) has also been reverse-engineered https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol and emulated http://torsten-traenkner.de/wissen/smarthome/openmilight.php on equally dirt-cheap nRF24L01+ modules in packs of 5 from China, getting us even closer to building the multi-protocol, multi-frequency "transceiver of all trades".

For the 433 and 862 MHz in particular, one might wish to buffer the RF into a tee-style duplicating FIFO from which it could be parsed in parallel (rather than from twice the hardware effort) by both LIRC and decoders for the various weather sensing / home control transmitters populating these bands.



Edited 2 time(s). Last edit at 09/29/2016 02:57AM by TEN.
TEN
Home (cinema) automation: Transceiver of all trades
September 30, 2016 03:34AM
bodhi Wrote:
-------------------------------------------------------
> I think TEN has this really good idea from the
> linked post. I've qoted here again to raise
> interests
> identify GPIO pins otherwise unused
> that might drive the Bodhi-ported lirc_rpi
> for RF(-to-IR) remote control transceivers
>
> With their open base and collector respectively,
> these particular TX & RX modules (though the
> latter should better be replaced with a superhet)
> might even interface with 3,3V without putting the
> ARM's voltage tolerance in jeopardy

> even possible to (re-)program and repurpose the
> JTAG header as GPIO during normal operations?
>
> use LIRC without a softcarrier and
> hence drive various radio transceivers
> I could help with the software part to expose them
> properly. But down to the board level soldering
> and electronics stuff, I'm not qualified :)
> perhaps Gravelrash and
> bobafetthotmail might want to chime in.

Wonder if we might have to split off the thread from http://forum.doozan.com/read.php?2,25496,25512#msg-25512 or so into a new one such as "Transceiver of all trades" in its own right for further development:
This one "Pogo Plug Mobile - Constant Orange LED after succesful Debian install <SOLVED>" looks so, erm, solved... ;)
Re: Pogo Plug LIRC
June 14, 2017 05:14AM
Did this ever go any further? I'd like to use my Dockstar as a poor man's Harmony Hub and have Alexa (via my Echo Dot) blast IR commands to my various AV components. I already have Alexa controlling things via my Dockstar using fauxmo, but everything has to be on the network.

craigcoffman used a USB IR transceiver, but that thing is something like 40 bucks. I'm way too cheap for that! If I could hook up a homemade serial IR transmitter (and/or receiver) to a GPIO pin or the serial port, that would be more in my price range. Looking at the LIRC documentation, it looks like more than just TxD/RxD are required. Are all the serial port pins even available on the header? Any options for using GPIO pins?

The mention of the weather sensing devices is intriguing as well. I'd love to be able to receive my wireless thermometer's signal on my Dockstar.

-JT
Re: Pogo Plug LIRC
June 14, 2017 04:50PM
Re: Pogo Plug LIRC
June 15, 2017 02:55AM
Thanks, I may give that a try. I also have a RPi0 lying around that I might try if I can roll my own transmitter. I guess I'd need a receiver as well to capture the codes in the first place. Hmm... that USB transceiver is looking better and better. I'm also going to get a few of those 433MHz transceivers from China to see if I can pick up the signal from my wireless thermometer. I need to do some research about how to get data into the Dockstar via a GPIO pin.

-JT
Re: Using Pogoplug for a "Transceiver of all trades"
June 15, 2017 06:26PM
That FLIRC FL-09028 USB is only a receiver. I don't have any need to control my Dockstar via remote. I'm thinking the only way to get this to work (at least on the Dockstar) is to appropriate the serial port pins since I don't see any other GPIO pins that are brought out to anywhere. I don't suppose there's a schematic of the Dockstar somewhere? I'm not sure how taking control of the serial port pins would affect other aspects of the kernel that are expecting the console to be there.

-JT
Re: Using Pogoplug for a "Transceiver of all trades"
June 15, 2017 07:21PM
renojim Wrote:
-------------------------------------------------------
> That FLIRC FL-09028 USB is only a receiver. I don
> 't have any need to control my Dockstar via remote
> . I'm thinking the only way to get this to work (
> at least on the Dockstar) is to appropriate the se
> rial port pins since I don't see any other GPIO pi
> ns that are brought out to anywhere. I don't supp
> ose there's a schematic of the Dockstar somewhere?
> I'm not sure how taking control of the serial port
> pins would affect other aspects of the kernel that
> are expecting the console to be there.
>
> -JT

No exposed GPIO for Dockstar. And I think you could disable the tty console to repurpose it for this task (we tell the kernel that there is no tty console).

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: Using Pogoplug for a "Transceiver of all trades"
June 15, 2017 11:07PM
Cool. I think I'll start experimenting.
Re: Using Pogoplug for a "Transceiver of all trades"
June 16, 2017 01:52AM
Well I thought I could muddle through without bothering you too much, but the phrase "getting nowhere fast" comes to mind. I tried changing 'console' in the u-Boot environment to "none" as well as "ttyS1", but in either case it doesn't boot (at least it doesn't show up anywhere on my network). I'm afraid if I keep screwing around I'll manage to get it to a point where I can't use the serial console at all. I also thought about using the LED control lines to experiment, but again, I guess since they're already configured somewhere, I can't control them through /sys/class/gpio.

-JT
Re: Using Pogoplug for a "Transceiver of all trades"
June 16, 2017 02:21AM
JT,

> I'm a
> fraid if I keep screwing around I'll manage to get
> it to a point where I can't use the serial console
> at all.

In serial console, if you don't save envs, you can change the bootargs all you want, nothing will mess up. If you are cautious, also backup your rootfs before testing.

With that said, to be absolutely sure you can do all the HW experiments you'd want, I would use a box such as Pogo V4, GF Home, Dreamplug,... all these low cost boxes have UART booting. The worst case with these boxes is you have to use kwboot to load u-boot and restore it to normal state.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: Using Pogoplug for a "Transceiver of all trades"
June 17, 2017 12:25AM
I have a spare Dockstar I got explicitly for doing experiments like these and an E02 that I haven't updated the u-Boot yet. I don't think either supports serial booting, but as long as there's some way of debricking, I don't mind if I cause myself a little pain.

I modified the DTB to remove the original UART0 entry and changed the UART1 entry to be UART0. It seems to work or at least it boots. I can now control the RxD and TxD pins via the /sys/class/gpio interface, so I think that's progress. If there was an easier way to get the kernel to give up control of the UART0 pins and take control of them myself, I couldn't find it. I'm assuming there's nothing connected to the original UART1 pins since it should have become the new serial console once the kernel booted, but I think that's a safe bet. Nothing has blown up, yet!

On to trying to interface to an IR transmitter. I'm going to try to emulate what this guy did on his RPi. After looking at various LIRC stuff, I have to agree with him that I'd rather not use it. I may try it at some point, but I think there's more that I can learn about Debian, the kernel, and the hardware by doing my own bit banging.

-JT
Re: Using Pogoplug for a "Transceiver of all trades"
June 17, 2017 11:11PM
JT,

-------------------------------------------------------
> I have a spare Dockstar I got explicitly for doing
> experiments like these and an E02 that I haven't u
> pdated the u-Boot yet. I don't think either suppo
> rts serial booting, but as long as there's some
>
way of debricking, I don't mind if I cause my
> self a little pain.
>
> I modified the DTB to remove the original UART0 en
> try and changed the UART1 entry to be UART0. It s
> eems to work or at least it boots. I can now cont
> rol the RxD and TxD pins via the /sys/class/gpio i
> nterface, so I think that's progress.

Cool!

> If there wa
> s an easier way to get the kernel to give up contr
> ol of the UART0 pins and take control of them myse
> lf, I couldn't find it. I'm assuming there's noth
> ing connected to the original UART1 pins since it
> should have become the new serial console once the
> kernel booted, but I think that's a safe bet. Not
> hing has blown up, yet!
>
> On to trying to interface to an IR transmitter. I
> 'm going to try to emulate what https://blog.
> bschwind.com/2016/05/29/sending-infrared-commands-
> from-a-raspberry-pi-without-lirc/]this guy d
> id on his RPi. After looking at various LIRC stuf
> f, I have to agree with him that I'd rather not us
> e it. I may try it at some point, but I think the
> re's more that I can learn about Debian, the kerne
> l, and the hardware by doing my own bit banging.
>

The /etc/inittab has definition for all tty consoles.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: