[quote author="Barf"]as far as I see, just hacking the firmware a bit (as you say, rather removing stuff than adding stuff) it should be possible to connect an RF module to one of the (unused) GPIO pins.[/quote]That's been the idea discussed for half a decade, but little used before LIRC supported the IR Toy and your driver made the softcarrier switchable.
Quote
Here is my Arduino software that, if configured correspondingly, sends modulated signals with IR, signals with modulation frequency = 0 will be sent by RF.
It should be doable to implement that with the IrToy. I am presently not "into" programming PICs, Although it is on my plan, PICkit3 present ;-).
In spite of a 5£/€/$ Pi Zero coming our way, the Girs code in particular looks like it so wants to run on a http://de.aliexpress.com/item/V3-4M-byt ... Title=true (and the even smaller but not much cheaper ESP01&3) much like http://randomnerdtutorials.com/esp8266- ... d-sockets/ WiFi-enabled these would be ridiculously more simple to place and less power-hungry than my current crop of ARM-based bidirectional LIRC2LAN gateways (that also handle the respective serial LCD/VFD)...
[quote author="Barf"]I am the person behind harctoolbox and IrScrutinizer[/quote]Thanks for joining & for your work! :)
Quote
If I understand the OP correctly, he want to transmit NEC1 signals with RF, possibly to have them reverse transformed at the device. In that case, the carrier should of course not be removed.
My understanding of how he mentioned radio and the original remote (decoded and to be emulated) being RF rather than IR... was that RF is what he actually intends to send from LIRC.
Quote
Lirc, the possibly most overrated program in the open source community...
Given how deeply it's now been "inkernalized" ;) and with almost all but FHEM based upon it: quite unlikely to be going away though (i.e. reality as per Philip K. Dick's famous definition).
Maybe the hardest part was for documentation (including the array of concoctions all across the web) to keep up with the turns in LIRC's development, especially when much had no easily accessible explanations and globally available ready-made dongles for people just trying to remote-control their media centers.
Especially with all the weather sensors and meter readings coming in over added ISM bands, I'd also prefer if there were simple kernel-side receive and send buffers sharable between LIRC and parsers for data transmissions (to avoid running additional receivers for the same frequencies on further GPIOs or even separate controllers), as well as to easily broadcast simulated datagrams, but I'm not the one equipped to implement (rather than just propose) any such extension.
Quote
Quote
there is a patched version of LIRC for the Pi
well, that is a driver that can handle non-modulated sends, not a lircd.
Sorry if I put too few words to the link further elaborating on this.
Quote
Actually, until recently, lircd could not at all handle "0 modulation frequence" at all. I have raised a ticked with a patch, https://sourceforge.net/p/lirc/tickets/132/ which has been accepted and committed, so it should be in the releases "soon".
"My" lirc_rpi driver is now "maintained" at Github.
Great, it's about time indeed for Linux remote controls to "officially" get the long-wishlisted viewtopic.php?t=431#p3702 extension of their scope to sufficiently high frequencies indistinguishable from magic. :)
Here's hoping that the IR Toy too will start shipping with multi-transceiver RF support soon (2.4GHz recently added to the challenge).
[quote author="TEN"][quote author="sidiouss"]I've redesigned IR Toy's v2 board a bit and managed to build it on my own and it works perfectly! I have decoded my Medion's radio remote control codes via the WinLIRC... I would like to build a 868Mhz tranceiver based RF remote controller for my radio which would transmit remote codes via IR diode attached to the radio IR receiver. Could you tell me how the IR frame should look like e.g for the standby/on button? I do not really understand the whole data in the config file and I do not know what and how should I send to the IR receiver.[/quote]Parts of the LIRC formats aren't so well documented, but they give the on&off times from which you can see how the pulses are structured (as you probably know in detail now that I am late to this thread).[/quote]In microseconds to be sure, and http://winlirc.sourceforge.net/technicaldetails.html + http://www.righto.com/2010/03/understan ... -lirc.html have been the best in a while.
Quote
The trick to sending RF is to turn off the IR softcarrier - there is a patched version of LIRC for the Pi and ported to the PogoPlug that can do this.
I've redesigned IR Toy's v2 board a bit and managed to build it on my own and it works perfectly! I have decoded my Medion's radio remote control codes via the WinLIRC... I would like to build a 868Mhz tranceiver based RF remote controller for my radio which would transmit remote codes via IR diode attached to the radio IR receiver. Could you tell me how the IR frame should look like e.g for the standby/on button? I do not really understand the whole data in the config file and I do not know what and how should I send to the IR receiver.[/quote]Parts of the LIRC formats aren't so well documented, but they give the on&off times from which you can see how the pulses are structured (as you probably know in detail now that I am late to this thread). The trick to sending RF is to turn off (or demodulate) the IR softcarrier, as discussed with respect to building the "transceiver of all trades" (or "eierlegender Wollmilchtransceiver" as your neighbors to the West call it) enabled for selectively sending&receiving 433&868MHz AM at least in addition to IR at viewtopic.php?f=29&t=7133 - there is a patched version of LIRC for the Pi and ported to the PogoPlug that can do this. Sadly, neither support for RF nor for the IR Toy itself seem to have made it into common distributions'/mainline kernels yet. Multi-frequency RF (possibly considering 2.4GHz OQPSK as well these days) is a much needed addition to make a huge difference to home automation where there seems to be no complete, programmable and affordable commercial solution.
http://www.harctoolbox.org/lirc_rpi.html in particular seems to have made great strides as of late to finally build an affordable integrated "transceiver of all trades" (cf. viewtopic.php?t=431#p3702) and high-resolution driver (e.g. mceusb is just 50µs AFAICS, too slow and inaccurate for many remotes) - some of (t)his work might serve as further inspiration.
Particularly extensive information on (E-)EDIDs is also provided by the VESA Display Data Channel Command Interface (DDC/CI) Standard and the http://www.onsemi.com/pub_link/Collater ... C208-D.PDF datasheet for an 8 kb Dual Port Serial EEPROM (which regrettably AFAICR does not seem to pass through traffic for device IDs other than its own A0/A1 between its two I2C busses, which would otherwise obviate the need for developing a custom microcontroller - but anyone with a Bus Pirate and access to these or similar ICs is welcome to try whether the I2C traffic for other IDs is actually passed on between ports while the documentation may just omit to highlight this feature).
To rekindle this thread with plenty of suggested reading (and a proposal of next steps), lest it be lost in a crash of any kind, or by limitations of the time I can dedicate to development:
Now that incompatibilities have multiplied as audio for various speaker settings on different endpoints (5.1 HiFi, display with 2.0 or projectors with 0.0 channels, all usually requiring a custom-crafted EDID combining the capabilities of various devices to get in particular Windows to play sound properly over any such combination) has joined the payload on the former "monitor" cables, I have recently come in contact with European HDMI switch makers and Asian connector manufacturers to explore the feasibility of a similar feat on HDMI/DisplayPorts.
The good news is, both of the latter still use a dedicated I2C bus, and even the proposed DisplayID successor to (E-)EDID will keep the 128-256 bytes EEPROMs. However, from HDMI onwards other traffic notably for HDCP handshakes also occupies the same I2C bus.
https://freedom-to-tinker.com/blog/felt ... -key-leak/ and http://cryptome.org/hdcp-v1.htm cover the concurrent HDCP protocol, which should not be of so much interest to us for the purposes of this discussion, other than implying that from HDMI onward, we need to use a microcontroller as a repeater passing through most of the bidirectional I2C traffic (possibly also including CEC remote control) but filtering out and replacing data for, and instead of transmissions from, the simple EDID EEPROMs usable on VGA&DVI.
Fortunately last year's aptly named BlackHat presentation HDMI - Hacking Displays Made Interesting demonstrates in open source the feasibility of I2C EEPROM emulation on a cheap [s:]AVR[/s:] (source says tested on Arduino Duemilanove, hence) ATmega168/328. With its routines for establishing a bus over SDA/SDL lines and serving EDIDs, this could provide a springboard for further development as outlined above.
One point not entirely clear from the above documentation nor fact-checked against much of the gear out there "in the wild" (a Bus Pirate might come in handy) is whether (and when) the EDID EEPROM's bus address is 0x50, A0 and/or A1 across the various types of connection, and if there are further device IDs to be filtered by a such microcontroller.
The ATEN VC080 HDMI EDID Emulator, the CYP Detective (German) and the Gefen HDMI Detective Plus are commercial devices available at present that seem to accomplish something similar, but occupy both considerable space and wallet share (per signal source, i.e. especially in a KVM or home cinema setup), making them less practical than the DVI solution where an EEPROM could simply be integrated into each display cable.
Finally the proper place for EDID/DisplayID emulation should of course be all input ports of HDMI matrix switches, ideally handled by their internal microcontroller and programmable over USB (or I2C) for each port, but very few manufacturers seem(ed) to have this requirement on their radar (at least unless contacted, which I encourage everyone to do as well).
Always been wondering why no cellphone maker would include a row of high-intensity LEDs to the side of its devices, with all other components (including the gyro/motion sensors) and easier entry of custom texts already on board these days.
[quote author="tayken"]I like how "NA" and "SA" are right next to each other and form "NASA" :D[/quote]Our motto too, "per aspera ad acta" (uniting hackers, makers and civil liberties lawyers), is of course a play on theirs (and many a political entity's) - "through struggle to the files" (so much rather than to the stars), by any avenue, loophole... or via. :D
This is where my proposal of using the I/O header to connect RF modules (cheap from eBay etc.) directly to the USB Toy (using baseband OOK without IR carrier modulation for these) comes into play:
In most jurisdictions, there are some 2 or 3 ISM bands available, each with a number of channels and allowing various modulations - so one would need a fairly huge mansion to run out of different RF transmitters/transceivers to cover each room with its own wireless IR extender (e.g. something like http://www.airwave.com.tw/IR-Extender.html or http://www.marmitek.com/en/catalogus/pr ... roduct=220 - fitted with another RF receiver module if need be) - or on some devices, directly fit a module to feed in the RF receiver output where they'd expect the demodulated IR.
[quote author="ian"] This is a moderate update of the IR Toy to be prototyped this summer and available maybe next year. Let us know what you think.
Changes: *Extra pins to header[/quote]
Will the firmware support RF module RX/TX connected to this JP1 expansion (like IR but just TTL with the softcarrier switched off) ?
While obviously there is no space for an optional MAX232, firmware support to use the serial port at least for an lcdproc-style output would of course be a welcome addition as well.
[quote author="liyin"] Is it possible to store a couple of codes in the IR Toy and with the help of a timer do the same thing, without having to leave the computer on[/quote]So-called "macro" functionality (whether triggered by incoming command, local button or on-chip timer) has already been one of the feature requests for a while: http://dangerousprototypes.com/forum/in ... 76#msg4576 (Importantly, the vast library at http://www.LIRC.org/remotes should be usable even in stand-alone operation, natively or through conversion on upload to the Toy.)
Others are RF support (actually a simplification rather than an extra feature, as it just means being able to send without the extra modulation required for IR) and the use of the UART (adding an option for the standard voltage converter to the circuit board) for serial control e.g. of a display or an AV receiver through their RS232C ports.
[quote author="rsdio"] International parts ordering is difficult. There are some chips which cannot be exported from the U.S. without special permission. For that matter, there are even chips that are available in every country EXCEPT the U.S. One of my clients has to order their regulator from Canada or the U.K.
For your sake, I hope there are hobbyists in France who can help you find a local source. I'm not certain, but I really doubt you'll find cheap shipping from U.S. sources for this kind of commercial parts supply. [/quote]Internationally, nearly "all things electronic" are available from http://www.rs-components.com/index.html - for the more common stuff across Europe in particular, http://www.conrad.com is a good start, and "traditionally" of course Her Majesty's http://www.maplin.co.uk
[quote author="TEN"] the UART could be put to general use (as in http://www.irtrans.de/en/shop/usb.php) for driving e.g. a VFD (cashier's display, simple 8o1@9600 baud output...) or to control a HiFi amplifier (...) in particular with a little extra hardware (optional MAX232) appealing to the VDR/MythTV crowd, besides the Home Cinema / Home Control enthusiasts who'll like the thought of remote-controlling their RF power sockets and roller blinds along with their AV gear anyway. [/quote]BTW "the competition" has published some interesting details on the reasons for their choice of components: http://www.irtrans.de/en/technicalinfo/
Another useful feature taking the TV-Be-Gone idea a step further could be the additional ability to wait stand-alone (independent of the PC on USB) for an incoming IR (or RF) command and upon reception start sending out a user-defined sequence of commands (including delays in between) to various devices: E.g. one single remote (or local) command could bring up all roller blinds in the morning, or in a home cinema, bring them down along with a projection screen and and appropriately set up the lighting, projector and surround system for a night at the movies (or sports events, before any soccer fans waiting for the World Cup start crying "insensitive clod" - but then again "the only thing left is to actually convince a human woman to go in there with you…" ).
Using the approach of optional unmodulated I/O (base band, OOK) proposed for RF, as well as rct's above suggestions for multiple I/O "zones" and FernetMenta's of being able to operate e.g. a PC's power button (known in VDR/MythTV circles as a "wake-up board), the latter kind of I/O could even be stored like remote samples for a kind of "Morse code" if the timers are large (i.e. "slow") enough to distinguish different ways of a human operator pressing buttons on both input and output: In FernetMenta's example, a standard PC power button, which could be (opto-)coupled to a USB Toy, reacts to a short click by going to sleep/waking up from stand-by, whereas press for a few seconds the machine shuts down, so the "USB Wire Toy" ;-) could also control both behaviors. On the other hand, the USB toy itself could distinguish either different buttons on a remote control to start sending "macro sequences", or different presses to its own ("local") buttons/inputs, if any.
Of course, this is complicated only to describe but would be very intuitive to use.
).