Girs client does not work with girs server 1.0.5

[DjordjeMandic]

Girs client does not work both on windows and linux.

I'm trying it on my own custom board but i cant get it to work. Serial works fine, server responds, just app does not work

GirsLite config

/**
 * @file GirsLite.config.h
 * @brief Configuration optimized for IrScrutinizer and Lirc.
 */

#pragma once

/**
 * Program name, as displayed in greeting messages etc.
 */
#define PROGNAME "GirsLite"

// Define Girs modules to implement, see http://www.harctoolbox.org/Girs.html

/**
 * Define to support transmission of IR signals. Requires IR LEDs.
 */
#define TRANSMIT

/**
 * Define to support the rendering of some known protocols, presently NEC1 and RC5.
 */
#define RENDERER

/**
 * Define to support capturing of IR signals.
 * Requires non-demodulating IR sensor (TSMP58000, QSE159, etc).
 */
#define CAPTURE

/**
 * Define to support reception of demodulated IR signals.
 * Require demodulating IR sensor (TSMP* or equivalent).
 */
#define RECEIVE

/**
 * Define to support decoding of the received signal.
 */
#define DECODER
/**
 * Define to support blinking with LED according to decoding outcome.
 */
#define DECODELED

/**
 * Define to support an LCD display with I2C connection. Defines a command "lcd".
 */
//#define LCD

/**
 * Define to use signaling LEDs. Defines command "led".
 */
#define LED

/**
 * Define to allow to change the parameters, like timeouts.
 * Defines command "parameters". The Lirc driver uses this, if available.
 */
#define PARAMETERS

/**
 * Define to support commands called by names, grouped in sets, "remotes".
 * (Not yet implemented.)
 */
#ifdef DOXYGEN
//#define NAMED_COMMANDS
#endif
//#define NAMED_COMMANDS

/**
 * Define to have the receive command report the durations, even if DECODE is defined
 * and a decode was found.
 * Use this for Lirc.
 */
//#define DONT_REPORT_DECODES

/**
 * Define to be able to reconfigure signaling LEDs during runtime.
 * Have parameters for transmitled etc.
 */
//#define CONFIGURABLE_LEDS

/**
 * Define to support sending signals without modulation, e.g. with RF module.
 */
//#define NON_MOD

/**
 * Define to support a reset command, Experimental!!
 */
#define RESET

/**
 * Define to support command "memory", reporting free (SRAM) memory.
 */
#define FREEMEM

/**
 * Define to support command "info".
 */
#define INFO

/**
 * Define to support command "hex", sending Pronto hex signals.
 */
#define PRONTO

#ifdef LED

#ifdef TRANSMIT
/**
 * Number of logical LED to light when transmission takings place.
 */
#define TRANSMITLED 1
#endif

#ifdef RECEIVE
/**
 * Number of logical LED to light when waiting for reception.
 */
#define RECEIVELED 1
#endif

#ifdef CAPTURE
/**
 * Number of logical LED to light when waiting for capture.
 */
#define CAPTURELED 1
#endif

/**
 * Number of logical LED to light when waiting for command.
 */
#define COMMANDLED 1

#endif // LED


/**
 * Character that ends the command lines.
 */
#define EOLCHAR '\r'

// Hardware configuration

// Define an LCD symbol to use, if desired.
#ifdef LCD

/**
 * Define to use LCD display at I2C address 0x3F,
 * 4 lines, 20 columns.
 */
//#define LCD_0x3F_20_4

/**
 * Define to use LCD display at I2C address 0x27,
 * 4 lines, 20 columns.
 */
#ifdef DOXYGEN
//#define LCD_0x27_20_4
#endif
//#define LCD_0x27_20_4

/**
 * Define to use LCD display at I2C address 0x27,
 * 2 lines, 16 columns.
 */
#ifdef DOXYGEN
//#define LCD_0x27_16_2
#endif
//#define LCD_0x27_16_2

#endif // LCD

// Include one file describing the pin configuration
// Use one of the provided, or write your own.
#include "girs_hw_config.h" 

// Without PARAMETERS, these are really not defaults,
// they are the non-changeable values.
/**
 * Time to wait for signal to start.
 */
#define DEFAULT_BEGINTIMEOUT 10000UL // milliseconds

/**
 * By receive, time to wait before signal is considered ended.
 * If using the decoder, be sure to end a capture before the repeat sequence.
 */
#define DEFAULT_RECEIVE_ENDINGTIMEOUT 50L // milliseconds
#ifdef CAPTURE
/**
 * By capture, time to wait before signal is considered ended.
 */
#define DEFAULT_CAPTURE_ENDINGTIMEOUT 100L // milliseconds
#endif

/**
 * Size of capture and receive arrays.
 */
#define DEFAULT_CAPTURESIZE 400U // must be even

#ifdef RECEIVE
/**
 * This quantity is added to all gaps and subtracted from all marks when receiving.
 */
#define IRRECEIVER_MARK_EXCESS 50
#endif

#ifdef CAPTURE
/**
 * This quantity is added to all gaps and subtracted from all marks when capturing.
 */
#define IRSENSOR_MARK_EXCESS -10
#endif

#if !defined(ETHERNET) | defined(SERIAL_DEBUG)
/**
 * Configured speed of the serial port.
 */
#define SERIALBAUD 115200

/**
 * Timeout for serial line.
 */
#define SERIALTIMEOUT 5000L
#endif // !defined(ETHERNET) | defined(SERIAL_DEBUG)

[DjordjeMandic]

Problem was baud rate error on atmega328p @8MHz

[bengtmartensson]

Thank you for your contribution. Glad that it is fixed. But, I did not consider atmega328p @8MHz as supported, so I would very much like a detailed description of what you did that worked, and what did not work.

[DjordjeMandic]

Alright let me explain everything so its more clear even thought this is more of a discussion for Girs project.

I have this board with ATMega328P on it. I modified tv-b-gone firmware for it and it works pretty good. "Recently" (designed 2 years ago) I decided to make(assemble) some expansion boards for it. Project was not planned at all for Girs initially but I made it work. IR Receiver is connected to PB4. Then I found out that non-demodulating receiver must go to PB0 (ICP1). Quick fix was 10k resistor between PB4 and PB0(ICP1). That now works fine but you gotta be careful with command choice depending on module connected.

Now actual issue. ATMega328P has different actual baud rate depending on clock frequency. Error is small but sometimes there might be problems with data parsing.

Here is table for 16MHz(Microchip document 7810D–AVR–01/15 page 165, Table 19-12):

And here is table for 8MHz(Microchip document 7810D–AVR–01/15 page 164, Table 19-11):

My board and CP2104 works perfectly at 250k, 500k and 1M baud. CP2104(IrScrutinizer) parses 115.2k from ATMega328P(Girs) perfectly besides [-3.5%, 8.5%] error in baud rate from ATMega328P. Problem is when ATMega328P(Girs) tries to parse 115.2k from CP2104(IrScrutinizer). Girs does not understand what IrScrutinizer sent and returns ERROR which causes IrScrutinizer to freeze and then throw an excepetion.

Now with 38.4k baud everything works great because of only 0.2% error.

Issue was on Girs hardware as per table and only fix is to change clock or baud rate. IMO 8482845 is perfect improvement for this. I prefer higher baud rates if hardware allows.

edit:
This might be helpful too to understand the problem (Microchip document 7810D–AVR–01/15 page 146, 19.3.2):

[DjordjeMandic]

I have one more question, as i understood baud rate selection is limited by native lib on host os used by nrjavaserial(for example termios on windows)?

So even if you wanted you couldn't do anything to add more baud rates or textbox for entering your own besides com port hardware support (for example cp210x), is that right?

[bengtmartensson]

I am not sure what answer you expect; you do not appear to be a person who is asking trivial question?! What I did yesterday was to add a number of "possible" values to the text box, not really bothering if the underlying software supported it or not. I looked for a getSupportedBaudRates() in nrjavaserial, but could not find one.

But remember that serial communication is an artifact from the IT stone age. (I really hate that Java does not support it officially, only ussing third-party libraries, like nrjavaserial, which is a development of RXTX.) There is already a TCP-sockets interface, fully supported in IrScrutinizer, and I am pretty satisfied with it. A native USB communication would come in naturally. Also MQTT/Zigbee/Tasmota... would be interesting. Do you have any suggestions?

[DjordjeMandic]

I understood what you did yesterday, simple and effective. Thanks for that. One more improvement if nrjavaserial supports it would be to implement a way to enter custom baud rate (since most usb-serial converters support non-standard baud rates). And that's it, serial configuration part is practically up-to-date.

As for network stuff, it would be best to implement AGirs for 32bit microcontrolers with wifi but in meantime simple 32bit mcu with wifi can act as bridge talking via serial to 8bit avr. New controllers from ESP32-xx series have a lot of features(BLE, ZigBee, Matter, Thread, WiFi), ESPHome/Tasmota support.

Individual implementation for MQTT in IrScrutinizer would be good, people could then configure their hardware how they like so that data arrives to Girs. To prevent collisions in case of multiple clients "busy" or "connectionestablsihed" topic would be good for start.

Since TCP socket interface exists nothing more is needed, everything can be implemented locally on 32bit mcu with wifi acting as bridge. MQTT could just be a bonus.

Girs over mqtt would be fun and useful. There would just be some work defining the mqtt topic tree.

[bengtmartensson]

Thank you for your comments. Just some remarks:

Integration with ESPHome and Homeassistent would be quite interesting.

to implement a way to enter custom baud rate (since most usb-serial converters support non-standard baud rates).

Sorry, I can not imagine a use case when this would be useful.

[DjordjeMandic]

Integration with ESPHome and Homeassistent would be quite interesting.

Then girs client integration for esphome would fit the best. Everything else can then be integrated via mqtt and native api. I will add this idea to my todo list