bengtmartensson / agirs Goto Github PK

This would consist of an infinite loop that calls some version of read, sending the received signal to a remote Lirc server using the Udp driver.

For sending, this is the transmit module in the specification: http://www.harctoolbox.org/Girs.html#Transmitters. It is not planned to implement these as independent channels, i.e. allowing them to send asynchronously.

For receiving and capturing, it should be possible to select from different hardware sensors.

The Girs.Lite.cpp in the sketch is blank which leads to the following error message:

Arduino: 1.6.6 (Mac OS X), Board: "Arduino/Genuino Uno"
stat /Users/janvikalra/Documents/Arduino/libraries/GirsLite/GirsLite.cpp: no such file or directory
Error compiling.

I tried the same sketch on a windows and got the same error message.

RF signals (433 MHz and other carrier frequencies) do not use the IR typical modulation. Also there are a few IR protocols (Revox, Barco, Archer http://www.hifi-remote.com/forums/viewtopic.php?t=14186&start=40). These should be possible to send.

Not needed now when "standard" Ethernet library supports all W5*00-chips. Just a useless option.

See README.md. Of limited usefulness, since there are cheap W5100 modules available (which, in contrast to ENC28J60, are compatible with the Arduino Ethernet library), just slightly more expensive.

Somehow (I have no theoretical explanation) IrWidgetAggragating seems to produce too short marks (bengtmartensson/IrScrutinizer#97) Adding a MARK_EXCESS should be a work-around.

Requires low-level fix bengtmartensson/Infrared4Arduino#6

http://www.harctoolbox.org/Girs.html#NamedRemotes

The list of remotes/commands can be either compiled in or read from a file on an SD card.

At least in the first version, no particular attention to performance or memory. Assume a Mega2560, or better.

Should not decode, but rather be a sort of IR recorder. Just write on a stream, as the present Listener. Cf recording a Glow with the Show show. Use signalling LED in a smart way.

Alternatively, should write on an SD-card. (Push-button for closing file?)

Should be used by a remote Lirc that runs the Lirc UDP driver. Just a listener that spits out its raw received timings to UDP.

Allegedly, the current version of the Ethernet library autodetects the chip (WS5100, WS5500 etc) which would make the ugly CPP symbol ETHERNET_REVISION unnecessary. Cf. #25.

Presently, we just deliver what is in the buffer when it got full.

• Possibly truncate at last "large" gap?
• Possibly indicate problem by flashing LEDs?
• Possibly some indication that truncation took place?

Arduino-Decodeir to be integrated. Only for boards >= Mega2560. Preferably support display on LCD display. ~~~Also the Listener should be supported.~~~

Have a CPP symbol `DECODEIR`; if defined, replace the built-in decoder `MultiDecoder` by a call to DecodeIR.

Configuration option for this:

If two pins are connected upon start, execute the "listener", otherwise the Girs program.

On the Nano setup pin 11 and 12 seem natural.

Currently, 2000ms is spent just showing which LEDs are working, preventing the program to take inputs. This is really annoying in particular for Lirc. Reduce to, say, 200ms.

The beacon should be integrated, of course only in the TCP/UDP version. There is a routine that should be called "every now and then" (no less than 60 seconds (say) apart), but a precise timing is not needed, so preferably a timer should not be sacrificed.

The current project organization is somewhat peculiar. This is only partially to blame on the Arduino idiosyncrasies. Most severely, it cannot be integrated into the Arduino library manager.

The project should be reorganized, and eventually submitted to the Arduino library manager. I do not know a possibility to avoid editing a configuration file within the library, so we will have to live with that. The "applications" should be turned into "examples", if possible.

There is a branch reorganization that contains a good start. Remains essentially the SIL testing parts, checking the applications/examples, and updating documentation.

First, just make a simple demo program that understands a few parametric input signals, and sends "translated" signals. Everything single-tasking.

This is essentially a small variation of the listener, see also the Opponator. Should (optionally) support debug outputs on Serial. Should support LEDs and LCD in the same way as the Listener.

Should be implemented as an "example", parallel to Girs.[ino|cpp].

Since the official shield (based on W5100/W5500), as well as the official libraries do not support IPv6, a substantial update of the official libraries is required.

More of a long-time goal; not immediately do-able.

Pointed out in private communication with Jan Ceuleers.

Is this driver in LIRC 0.9.3 or do I have to compile the specific version of LIRC from https://git.code.sf.net/u/bengtmartensson/lirc?

Applies to both AGirs and GrisLite, (possibly Girs4Lirc). Cf bengtmartensson/IrScrutinizer#92 (comment)

For this, there should be a second argument of IrWidgetAggregating::newIrWidgetAggregating in capture(Stream&).

The Lircd socket command interface on TCP port should be supported, as alternative. Cf. JGirs #2. SEND_CCF_ONCE should also be supported.
Not really meaningful without #13.

Requires #37.

Can be an Example, parallel to Girs.[ino|cpp].

Alternatively, this can Should be an independent project in the vein of GlobalCovfefe

If I issue a send command after a receive command to GirsLite, I end up waiting for the receive to either get a signal, or to time out (default is 10 seconds) before my send command is executed.
I would like to have a way to interrupt the receive in GirsLite before the timeout elapses, by sending a command such as "end receive", and having it take effect immediately.

Hi. (From rafi, relayed as requested)

I just wanted to inform you that my account has temporarily been flagged on github. Probably got stuck in some random spam filter bot.

I submitted a ticket to GitHub but it may take a while to fix.

In the meantime the repo is inaccessible, any chance you could somehow post an issue on one of bengtmartenssons's repos just to let him know?

Your email is the only one I have from the community.

Thanks,
Rafi Khan

1. It should be possible, for the user during run time, to select that a particular LED should go on (or off?) for particular events, like sending an IR signal, or waiting for a command or a signal reception. These should be governed by parameters, settable with the parameter command.
2. More fine-grained turn-offs of the LEDs. Presently all are turned off when a timeout is detected.

Split current GirsLib into GirsIrLib (which basically is "compatible" with IRLib and IrRemote), and GirsMiscLib (rest of the stuff like LED and LCD support, tokenizer,...).

Options (cf main Girs)

• SESSION
• not: SERVER
  _ UDP als alternative to TCP

LED & LCD support

Windows version of the flasher script GirsLite-$VERSION-nano-flasher.sh as bat file. Should use avrdude, per default C:\Program Files\Arduino\hardware\tools\avr\bin\avrdude.exe with avrdude.conf as C:\Program Files\Arduino\hardware\tools\avr\etc\avrdude.conf. Should support double clicking, a console pops up and asks for COM-port.

This has a very low usability/effort ratio. Probably cannot be done with 16MHz hardware. Neither can our favorite sensors like TSMP58000 be used, since they end at 60kHz.

It "should" be possible to port this project to the IrToy, preferably using the IrToy boot loader. It has a PIC 18F2550 processor.

The official v22 firmware is found here. The v23 sources appears not to be available.

Should probably be a top-level project on its own.

No need for a complete implementation, just the main, IR-related commands of GC-100/Flex.

Commands:

• getdevices (just return something trivial that later the sendir command accepts, like a Flex with one transmitter)
• getversion
• get_NET (?)
• blink(?)
• sendir

Everything single threaded: accept command, process, print output. (stopir is thus not to be implemented.) Only one connection at a time. Should return compatible error codes.

Can use LEDs to indicate state (listening, sending,...).

Probably should incorporate the Beacon.

In the Arduino package, can be an "Example" parallel with Girs.[ino|cpp].

Write as much as possible stream-based, but no need (at least initially) to support anything but TCP-server mode (just like the GC devices).

First version only support one sender, no receivers/captures. Several sender, learning (get_IRL) can be implemented in a second phase.

I am using GirsLite with lircd (versions 0.9.4d and 0.10.0) and I see that button presses get reported late. Although this can be solved via a configuration change I am reporting it to save time from others.

By default and for most configured remotes, lircd has a large receive timeout. This timeout is called LIRC_SET_REC_TIMEOUT by lircd and receiveending in girs. In my case it was over 100ms as the gap for my remote in the lircd configuration was unnecessarily large (as is in most available conf in the lirc site). Also by default the chosen receive window is 172ms because lirc comes with the devinput remote that has a large gap.

This is a problem because for some remotes many codes can fit in the receive timeout. The first problem is that lircd may drop times because its buffer will quickly get full (with the message "girs: readline buffer full:").

Even if we increase the buffer (by raising LONG_LINE_SIZE in the girs driver) we still have a second problem which is caused by the fact that lircd is designed to decode a single code with each receive command to the driver. If we press two buttons in say 172ms the following may happen:

1. lircd unblocks in mywaitfordata in the main loop
2. girs receive gets called, and eventually girs readdata which reads from girslite one line with the times for both buttons in the buffer
3. the code is decoded and lircd reports the first button press
4. the main lircd loop blocks in mywaitfordata

The second button press is not reported. When something unblocks curl_poll in mywaitfordata (like a third button press) we get the second button press reported with a significant delay.

Note that timing is important. It is possible that the Arduino is still transmitting the second code when the decoding of the first ends, in which case mywaitfordata will not block. Of course the problem may happen with more button presses.

We can avoid this problem by reducing the gap for all the remotes in the lircd configuration. This was the gap line for my remote:

begin remote
  name  Samsung_BN59-00603A
  bits           16
  ...
  gap          *107567*

An alternative workaround is to modify girslite to not update receiveending from lircd and set a low DEFAULT_RECEIVE_ENDINGTIMEOUT value (for me 30ms was enough).

If a smaller receive timeout is not possible (for example if you have two remotes, one with long and one with short codes) I know no good solution.

Drop file from repos or change
#ifndef GIRS_PINS_NANO_H
#define GIRS_PINS_NANO_H
into
#ifndef GIRS_PINS_NANO_SHIELD_H
#define GIRS_PINS_NANO_SHIELD_H

but values will still depend on include order.

Vss is not considered as a good notation for a positive supply voltage.
https://en.wikipedia.org/wiki/IC_power-supply_pin
(However, an accepted authoritative standard does not seem to exist, only "conventions".)

Suggested by Daniel Ford in a private message.

Emulate the Lircd server, the --listen option. Requires Issue #8.

Either in the main README.md or as a separate document.

This should depend on Infrared4Arduino only.

Should be submitted to the Arduino library manager.

Possibly it it possible to make a version that uses IRremote?

Alternatively merge into Infrared4Arduino.

Just the speed must be adjusted.

Not much to do really... Cf. issue #2.

Thank you for producing a girs_pins_micro.h file to support the Pro Micro. I take it from the following section:

#ifdef LED
#define SIGNAL_LED_1 2
//#define SIGNAL_LED_1_GND 3
#define SIGNAL_LED_4 A0
#define SIGNAL_LED_4_GND 15
#define SIGNAL_LED_3 A2
#define SIGNAL_LED_3_GND A1
#define SIGNAL_LED_2 A3
//#define SIGNAL_LED_1_GND 8
#endif

that I would wire up the LEDs as follows:

1. Is the LED wiring immediately above correct?
2. What about the fact the Pro Micro has no built in LED? What does #define SIGNAL_LED_1 2 end up doing for Pro Micro?
3. To direct GirsLite to use the new Pro Micro pin definition file, I think I need to add #define ARDUINO_AVR_MICRO to GirsLite.ino, correct?

I can understand that you might not want to get too involved in the particulars of the Pro Micro since you use and support the Nano yourself, however, at least inform about the best approach for directing the compiler to use a specific Arduino version - there are no comments in the source files that I can see on where to put the #define ARDUINO_AVR_XXX directive.

I'm planning on building this board http://fritzing.org/projects/agirs-dht-non_mod-433-tx that I've designed over the weekend and I'm hoping to get around to building support for ESP8266 via the library - I think this will mostly be a swap in over the ethernet library which I believe is much the same.

Using the basic anatomy of an Arduino sketch

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:

}

will help this to get widespread adoption in the Arduino community, as will using the basic anatomy of an Arduino library.

"boolean" is an abomination, cf. arduino/Arduino#4673