Troubleshooting, Miscellaneous

Frustrating couple of days, because the Speedbrake control wasn't work. Turns out there were multiple problems.

1. I was setting the value for speedbrake_ratio as an integer. Apparently this doesn't work, started working when I changed to float. The Raspberry Pi converts the boolean on/off from the switch to float properly. As long as the plugin copy of the a4SimConfig.json shows the simulation to need float.
2. I'm using Arduino Mega from the throttle quadrant. I connected the Speedbrake Open input to Arduino Digital channel 26, and for some reason the internal pullup resister either doesn't work, or is inadequate. Had to add another pullup resistor to +5.
3. The logic to respond to inNonZero was not properly working. As of this writing, this part seems to be configured correctly.

Had problems getting communications to work with Arduino Mega 2560, with 2.8 TFT display. The display was showing flight control positions in an “X.” It would work for a couple of minutes, then lock up. Wrote testing code to run in the Mega, then later ran it in an Arduino Uno to see if the problem was caused by the Mega. Problem continued in the same way.

Tried various things to get this working.

Pull-Up Resistors

I added pull-up resistors to the I2C channel. Sadly, I used the wrong values (too much resistance), which didn't fix the problem. After trying lower values (750 ohm worked, 1.5K ohm did not), settled on 950 ohm.

Change I2C Baud Rate

Experimenting with the I2C Baud Rate is what made the solution become apparent. 100Kbps is the default speed. When I changed the rate to 10Kbps, it all started working. 50Kbps continued to fail. Changed to 200Kbps, failed the same, until changing the pull up resistors as described elsewhere.

Multiplexer

Implemented a I2C Multiplexer so that individual I2C devices can be separated to their own channel. This also allows additional cable runs. This was a hardware change, as well as a software change. The Raspberry Pi must change the I2C channel (if needed) before sending/receiving to each device. This also adds isolation so that more cable can be used. Basically 1 Meter per I2C bus.

Placed stronger pull-up resistors between SDA and SCL and +5V. Tried different values. 950 ohm worked best. Was able to change the I2C Baud rate to 200K.

These resistors are soldered to the Arduino Mega 2560 Channel 46.

Additional Solution: In Arduino code, the I2C handler is looking for a fixed number of bytes on the inbound message. If it doesn't receive that many bytes, misbehaving code will just print an error message and go on. Was able to get the code to work by calling Wire.read() to read off the errored number of bytes.

With code like this:

    // Read off all of the bytes
    for (i = 0; i < numBytes; i++) {
      byteBuffer[0] = Wire.read();
    }

The Arduino with the LCD display on it stopped working. I had started changing the voltage of pin 2 of the JST connectors to be 12 volts instead of 5 (because connected devices need 7 - 12 volts because their internal regulators always drop at least 1 volt). I had plugged a 12V adapter into the barrel power socket of the Arduino Mega 2560 and things started behaving badly. Specifically, that Arduino got very hot, then stopped being visible when connected via its USB connection.

Noticed that the 4-pin JST connector had shorted to a neighbor pin. This pin was the 12V pin, and unfortunately, the breadboard connector of the Mega 2560 was not blank, rather, two rows connect to the various IO channels. So I was feeding 12V into one of the IO pins with a maximum of 5V. It may have recovered, but I kept running it to try to troubleshoot the problem.

After fixing the breadboard traces, I replaced the Arduino Mega 2560 (Channel 46) and it is working again, now powered by the 4 pin JST, with 12V input.

Tried to upload in the usual way to Arduino Nano from emakefun.com (very cheap, from Amazon). I kept getting obscure communication errors.

Resetted Nano, then need to select “old bootloader” when connecting. After doing this, worked fine. This is apparently because the new bootloader changes speed after connecting, but the emakefun is not expecting this.

[3/13/2020]

Worked on getting two OLED displays to work at the same time connected to an SoftI2CMaster I2C implementation. This was caused because the byte buffer each took about 1K of memory, but there is only 2K of Dynamic RAM. Solved the problem by reusing the buffer between the two displays.

[5/5/2020]