Raspberry Pi 3 – NTP problem solved – some power issues

Published by:

I got a Raspberry Pi 3 recently and installed the official Raspbian image from raspberrypi.org.

I came across a couple of issues:

  1. NTP would not sync.

ntpq -p would show that all the servers were in a state of .INIT.

ntpdate would work but ntpd would not.

It turns out that the kernel driver for the built-in WiFi chipset can’t handle the NTP packets over UDP. The solution is to add the following to /etc/rc.local:

/sbin/iptables -t mangle -I POSTROUTING 1 -o wlan0 -p udp --dport 123 -j TOS --set-tos 0x00

and reboot.

This is discussed on the raspberrypi.org forums at https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=141454

  1. Power management is a problem running it off an Anker 10-Port charger (http://www.amazon.com/Anker-10-Port-Charger-Multi-Port-PowerPort/dp/B00YRYS4T4)

I knew that the Raspberry Pi 3 drew more power but it seems to be unstable with this particular charger. That’s not to say the charger is at fault, it’s running 6 other Raspberry Pis quite happily but they are older models and I don’t think the ports supply the required current. I’m ordering a 5v 2.5A power supply to see if that resolves the issue.

The WiFi chip needs to have power management disabled to get it to be responsive.  To do that, you can create a file /etc/modprobe.d/8192cu.conf and add the following:

options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

I’m not certain this is addressing my immediate problem but once I get a more powerful power supply, I’ll be able to check.

UV Light Box – Part 2 – Control Interface

Published by:

I spent a lot of time working out how I wanted the controls to work and designed the software in C first so that I could work out a generic menu system that allowed me to configure it via an array of menu items.

The definition of the menu items is:

typedef struct {
 int id;
 char *label;
 void (*display_action)();
 void (*select_action)();
 void (*up_action)();
 void (*down_action)();
 int submenu_id;
 int prevmenu_id;
} menu_t;

So each item has an ID and a label followed by a set of actions. When the menu item is first displayed, it’s either the fixed label or, if the label is empty, the display action is called. This allows me to vary the display for things like the timer counter start value where the operator can choose the length of the timer. The select, up and down actions are function calls to vary the behaviour but the left and right actions are always to move to the parent menu or to a submenu.

This structure means that the actual menu handling code is relatively simple. Each button press will call the appropriate function in the structure. It’s the actual functions that can change and I can code for those as I go along.

The code itself is called inside the Arduino loop() function so I’m not using interrupts for the timer and the processor isn’t stuck in delay() cycles. Each time I go around the loop, I am taking the current number of milliseconds since the processor started up and compare that to a previous value I took. If the difference between the current and previous values is over a threshold, I take an action. For a timer, the resolution is seconds so I take the action to update the timer every 1000 milliseconds. For button checking, I take an action every 125 milliseconds.

This video shows the timer and menu system working. I still have some bugs to iron out in terms of timing but it’s working as expected.

UV Light Box – Part 1

Published by:

I’ve been playing around with etching my PCBs for projects and using toner transfer to do that. There are some problems I have with that method ( that’s not to say it’s not a good method, it’s just that my results haven’t been as I would have wanted them ) and so I’m starting a project to build a UV Light Box to expose UV-sensitive film to UV light as a different way of creating a mask for the etchant. This video starts that journey:

 

Roombaduino – part 24 – Simple UI

Published by:

I took a little time to look at the design for a simple UI for the Roombaduino. I needed to know the voltage level, which brushes are in operation and what mode the Roomba is in.

During this, I was getting a notification from the Arduino IDE that I was going to run low on memory using the example sketches and some of this is down to including the Serial library for debugging output. Once I stopped using that, the sketch was at 44% memory usage compared for 65%. Given that the amount of memory available

Roombaduino – part 23 – Custom connectors and working modules

Published by:

I put together some custom cables with ribbon cable, heat shrink and connector pins to replace the breadboard pins I was using. These connectors are a little more resilient.

I connected everything up including the wireless transceiver and tested the modules both with the I2C scanner and the serial monitor with the initial remote control sketch.

Everthing seems to be working fine so I now need to get the sketch on the main MCU to send data to the Roomba again and then I’ll start work on the case.

Roombaduino – part 22 – New Wireless module

Published by:

The remote won’t work unless it can transmit commands so I soldered up a new Wireless module. Because the Wireless transceiver uses SPI, some pins are shared on the ATTiny84/85 so I decided there would be a direct connection from the ATMega328 to the Wireless transceiver.

I also purchased some AMS1117 3.3v regulators to avoid needing to put a 5v-to-3.3v convertor myself. This reduced the amount of soldering considerably.

I had to solder some extra headers to the board so that the transceiver could be supported. The idea was that I could make the transceiver removable.

This may bite me in the future in terms of size of the case.

Roombaduino – part 21 – New joystick module

Published by:

Next part to get converted to I2C was the joystick module. This time I needed to use an ATTiny84 because I needed 2 pins for X and Y, 1 pin for the button and 1 pin for the LED plus 2 for I2C which means there are not enough pins available in the ATTiny85.

Soldering was a little easier because there are not so many connections required.

I also cut down the size of the module so that I could build 2 and put one either side of the main remote. This makes it a more compact unit.

The obligatory video below shows it working.

 

Roombaduino – part 20 – Soldered LED Module

Published by:

After breadboarding the LED module, I started on soldering the components. It was after I’d soldered everything and was finishing wiring the connections that I discovered that some joker had replaced my 16-pin sockets with 14-pin sockets and I was missing 2 pins for the last 2 LEDs. There was much wailing and gnashing of teeth as I started again.

This time I made sure I counted the pins and was able to complete the module in a couple of hours.

The ATTiny85 was still running the sketch to count in binary from 0 to 255 so that acted as a great test that the micro controller could control the shift register.

All that was left was to change the sketch so that it could read the data from the main MCU and output a byte to the LEDs. As luck would have it, the value of the button state can be directly applied to the LEDs so that the corresponding LED lights up without any need for translation.

WARNING: There are flashing LEDs in this video.

I build a simple bus with 8 ports where 1 port is connected to the main MCU and the other modules can just plug their 4 pins into one of the other connectors. I’ll make up some simple cables so that I can stop using my breadboard wires.

Next step is to build a joystick module with an ATTiny84 ( with more pins ).

Roombaduino – parts 17, 18 and 19 – Redesigning the remote

Published by:

After building the new IO board, I started to realize that my idea to have the remote control in modular sections needed a redesign. Each module needed at least 2 17-pin connectors to provide communication from the previous module to the next and that was taking up valuable space on the small perfboard and that required components to be squashed together ( ultimately exposing my lack of fine soldering skills ).

I was looking at controlling multiple OLED screens and found a technique that used a multiplexer to allow the controller to talk to OLEDs with the same address. The multiplexer switches the I2C data line between each screen.

Using I2C got me thinking about how I could redesign the remote control modules with just 4 pins for the bus ( 2 for power and 2 for data ).

To communicate with each module, I needed a smaller microcontroller that would respond to I2C requests from the main MCU ( the ATmega328 ) and send data back. This meant that I could have the module MCU talk to a shift register to determine button presses or to light LEDs.

I chose the ATTiny85 because it was much smaller and didn’t require a separate oscillator for timing and also didn’t need associated smoothing capacitors for power. However, with fewer pins comes less flexibility. The shift register technique needs 3 pins for control ( data, shift and latch ) but I also needed an input pin for the button module. The ATTiny85 doesn’t have enough pins available to do that. By happenstance, I found that I had a solitary Johnson counter that has 10 pins for output and a one pin for clock. Each time the clock pin is taken high, the output pin is incremented so, for example, if the output pin is pin 1, a clock pulse moves it to pin 2 and so on from 0 to 9. When it reaches 9, it rolls back to 0 again. Additionally, there is a pin to reset the counter back to 0. This is important if you want to poll buttons sequentially. The reset allows you to start from a known state.

So, the module uses 2 pins ( clock and reset ) plus the data input line instead of 3 + input. That makes the Johnson counter perfect for the button input module.

I needed to make sure that the ATTiny85 could talk over the I2C bus to the main MCU.

With that testing done, I could then solder up a new Nerduino and button module. I was also able to test that the ATTiny85 could light an LED module. Given that I don’t care about any input on the LED module, I can go back to using a shift register for that module and still only use 3 pins on the module MCU.

Roombaduino – part 16 – Working IO board

Published by:

In soldering up the new IO board, I had to make some changes to the joystick panel to make coding for the button presses easier. For each shift register, I have 4 pins for LEDs and 4 pins for buttons. If I press a button, I can now use some simple bit shift logic to light up the corresponding LED. Unfortunately, the joystick panel wasn’t wired up like that so I had to de-solder and then re-solder some connections to fix that.

Also, I had the shift register Output Enable pins pulled permanently to ground which meant that every bit that got written is immediately copied to the output pins. Now that I’m shifting data across 2 shift registers, I could see the LEDs flicker. So, I used up one of the 2 remaining pins on the MCU “bus” to be the Output Enable line for all the shift registers.

Now, when I’m writing data, I make OE high, write all the data and then make OE low to copy the data to the output pins. Problem solved.

Next step is to integrate all these changes into the remote control sketch and then work on the Roombaduino code to act on the new commands.