Project Logs

Collapse

• First production run

  Tiit Rätsep • 08/07/2015 at 10:17 • 0 comments

  Just now I received the first shipment of PCBs from the assembly house. We had all the SMDs populated in the factory but decided to do THT ourselves because most of the larger components have to be soldered in a very specific way to fin into the case. So now there's a crate with 200 assembled RISE control boards behind me and I can't help but feel a bit worried about what's going to happen next. We will need to solder each of these boards to the back of the motor, solder all the connectors, program, test .... 200 times. And this is just the first test run. We have already pre-orders for all of these and more. Some very interesting times are ahead of us. We estimated that each of these boards will take about one hour to fully assemble, test and flash with the release firmware. That means 200 hours just for this small step. Considering the cost of labour here in Estonia this final assembly will be one of the most expensive parts of this product. I'm very glad we spent the time and effort to make this thing so easy to assemble - there are actually no wires to solder anywhere, the only wire is from the battery to the main board and that has a JST connector so it's very hard to make any mistakes in assembly.

  We should get the plastic parts back from the factory either today or sometime next week. We will test the fit of all parts and then a test run of 1000 plastic sets will be made for us. All the plastic molding stuff is a first for us and it really seems so much more complex than it should be. We have been working with multiple companies to get the best value for our money and, no, we didn't go with the cheapest ones - we actually used one of the most expensive offers but still there have been numerous problems with the injection molds and the quality of the test pieces. But hopes are high that eventually we'll get what we want and we can ship something that we can be proud of.

  We have had this thing up for pre-orders for some time now and we are selling something like 10 each week unless we get featured in some weird web news thing and then things pick up momentum for a while. I personally never expected this thing to sell as fast as it does right now - I have much more hope for RollyCat when we finally get to shipping that.

• Reducing motor noise

  Tiit Rätsep • 05/19/2015 at 14:35 • 0 comments

  We have been hard at work on preparing RISE for mass production. We have ordered the molds for the plastic parts and at the same time we are still working on the electronics and the packaging. Our biggest concern at the moment is noise - the motor is simply too loud. To fight that we had to reduce the speed. Since we are using the same motor driver we did in RollyCat we know it can be driven by PWM but the built-in timers in the Nordic nrf51 series have been giving us a lot of trouble in the past. The way the nrf51 generates PWM is not completely separated from the core and every timer interrupt needs to be serviced. Since the BLE Softdevice is very time critical sometimes it's possible to miss the lower priority timer interrupt and that causes the PWM output to invert (since the output pin is toggled in the interrupt). There is an updated PWM library available for the SOC and we have now implemented that to test if we can improve noise performance without causing other issues. Another thing we are concerned with is if the PWM will interfere with the touch button. We are just testing that now and hopefully we'll have an update on the injection molded parts very soon.

  Going to be and exciting summer...

• Testing...

  Tiit Rätsep • 04/21/2015 at 06:36 • 0 comments

  The longest and most tedious part of any project.

  We need to test if RISE can survive on the sunlight (or lack of it) we have here in Estonia. For that we have installed 4 sets on the windows of our room and set them up to move a few times during the day. We have all of them connected to solar panels and have updated all firmware to the latest power-optimized version (using OTA so no more opening the case to reprogram the device).

  To see what's going on inside RISE we have created a few debugging characteristics for reading over BLE. One of these reports the battery level as measured by RISE. To log that I created a python script that uses pygatt to communicate with the BlueZ stack on my Ubuntu machine. It does work ... sometimes :). The problem is that pygatt uses the command line tool gatttool in interactive mode (basically calling command line tools and reading the text output). All that makes the thing very flaky and unstable. It is incredibly slow to begin with and if you add to that the fact that the calls often fail or time out this script becomes next to useless. Even worse - sometimes pygatt fails to close a connection and leaves a device connected for a really long time.

  I tried compiling BlueZ from source and using the newest version that has better support for BLE (specifically D-Bus support for BLE) but I failed to get that to install correctly for my system. Somebody should really look into making a native BlueZ library for Python. If only there were more hours in a day...

  Back to testing. RISE needs to work without external power on just solar energy. The problem with testing something like that is that we can never know what the exact conditions are at any specific clients location. Estonian winters are really dark and we can go for weeks without much sunshine. It would need to ride through those periods on just battery power. Unfortunately we have only recently started real window testing and we can't really wait until winter again. And all this testing is taking SO LONG....

• Power optimizations

  Tiit Rätsep • 04/14/2015 at 14:25 • 0 comments

  Long time since I last wrote here. We had some contract work and there was not much progress on RISE. This week we have been working on testing the solar panels and charging. We needed to minimize quiescent power to maximize the amount of energy stored per day. For that we needed to track down what was consuming the most power. To do that I started from an empty board and only populated the power supply part. Measured it's consumption and outputs - all ok. Then added blocks of functionality one by one and measured total consumption. I found out that the main power consumers were our GMR sensors. Each sensor uses up to 10 mA. That's way over our power budget. To fix that we needed to be able to control the power supply of these sensors. For that we spun a new version of the board and fixed the firmware a bit. Since we need the sensors only when the motor is moving we'll have the power supply turned off for most of the time and only turn it on with the motor. We also wrote in sleep modes for all the peripheral chips on the board and optimized the debug code. Still having debug printouts enabled increases our consumption by over 1 mA. The weird thing about the nrf51 chips is that after being flashed they will have an internal debugger active and the only way to go into really low power modes is to power cycle the chip.

  We spent a whole day chasing a very weird bug. After we got the new boards we had the firmware turn the magnetic sensors on and off at specific times. Well after that fix our code started to fail at random times. The failure seemed to be that for some reason one or both of the magnetic sensors stopped giving out a signal. At first we were sure it was something in the electronics and we debugged that part a lot. But on a scope and logic analyzer the outputs and power supply of the sensors were behaving perfectly. It turns out the way we were reading the sensor signals in a GPIOTE interrupt on the nrf51 was being broken by the commands that turned on and off the pins internal pull-ups. For some reason that caused the interrupts to work erratically - it still worked most of the time but failed every now and then. The fix was to re-enable the interrupts after each change to pin configurations was made. That seems to have cured this nifty bug for now.

• Update #3

  Tiit Rätsep • 01/30/2015 at 17:41 • 0 comments

  We were stress-testing the prototypes today and found problems with reliability. We can control the device by phone very nicely since we have most of the device state stored in non-volatile memory. But for testing we just set some volatile variables to run the test and found that when left overnight something would reset the SOC. At first we thought it was the relatively violent action of stopping the loaded motor with a strong current in reverse. But removing that didn't fix the problem. We may have some errors in the logic of our device and such things are a pain to debug as they only repeat very rarely. We have debugging functionality built into the firmware and we will have to monitor the logs to see what happens just before the device resets. This isn't a showstopper for us but still another little annoying thing to deal with.

  I was assembling two more prototypes today. It takes so long to actually build these boards by hand. Sure I did other stuff too but basically I dealt with this for most of the day. Soldering 0.5 mm pitch QFN and 0402 passives by hand is bad enough without having to run to a meeting every 15 minutes. But at least we'll have two more devices for our programmers and testers now. We have been dealing with this project for so long that we had accumulated a heap of devices of various vintage and most are not board level code compatible. So we had to build a custom firmware for almost every device until now. Now we'll have all pretty much the same hardware so at least we can't blame bugs on old pcbs and wiring any more.

  We also received some new TI current sensors today to test. The weird Microchip things we were using are still duds. I did hear back from Microchip support and they requested more information but I will try the TI ones first since all this drama has left me hating Microchip and if possible I'll go with TI. Since we are using a motor driver from TI anyway it will be easier to source components later too so it's not just my being angry.

• Update #2

  Tiit Rätsep • 01/28/2015 at 16:58 • 0 comments

  Today I worked on minimizing power consumption of the device. I found a serious problem with the sensors we are using. We use GMR magnetic sensors to detect a rotating magnet. We couldn't use the more common hall effect sensors because we need to sense a tiny magnet quite far away and the GMR sensor is much more sensitive. But the problem is that it uses a lot of current. Something like 10 mA. Our whole power budget for this thing is ideally under 1 mA. Right now we can go from about 1 mA to about 20 uA average by changing the advertising interval. We are going to try and get the optimum point with acceptable current draw and fast response times but we definitely need to stay under 1 mA average. So these sensors are going to be a problem. There is an easy solution but that will require a new spin of the PCB. Since we know we only need the sensors to work when the motor is powered we can just tie the supply voltage for them to the motor driver enable signal and we can save a lot of standby power. When the motor is moving it's going to be drawing something like 0.5 ... 1.5 A anyway so the sensors won't really matter there.

  At the power level we are operating at every little thing counts. So we had to make our main loop faster. We had to remove all unnecessary pull-ups from pins that didn't really need them. We needed to configure all pins with analog voltages on them to disable digital input buffers. We needed to disable all the peripheral blocks that we don't use and even the ones we use we have to enable only for the brief times we actually need them. We are turning the main 16 MHz oscillator off for most of the time. We did add a 32.768 kHz external crystal to the board but right now there seems to be a problem with using that (connection drops in about 30 s). The Nordic SOC has amazing power saving features built-in. It controls the main oscillator very well if you just follow the guidelines given. In addition it has superb support forums and sample code. The thing that amazed me the most at first was that it's possible to run all the low frequency timing operations from an internal RC oscillator that is periodically calibrated against the main 16 MHz crystal source. This does add about 10 uA of average current draw and is not very precise in the long run. We are trying to run a software RTC and it's drifting a bit. So we plan to use the external crystal instead of the RC but for some reason that is giving us problems at the moment.

  Tomorrow is a new day and a new chance to tackle all these issues.

• Update #1

  Tiit Rätsep • 01/27/2015 at 17:31 • 0 comments

  Today we found out that a capacitive touch button right next to a big motor might not be a good idea. Actually we were worried about that for a long time but the only way to be sure way to actually test it. The main problem is that we need to detect touch from about 6 mm away through two layers of plastic. And the other side of the PCB is right against the back of a DC motor. We are using an Atmel touch button IC that we tried on a prototype and it seemed to mostly work but had some spurious touch events. The new PCB has a much better layout for the touch sensor and without the motor it works beautifully. The problem is that this Atmel chip has a feature for stuck on state detection. And when we turn on the motor the button senses that as an on condition and if the motor runs long enough it recalibrates. After recalibration the touch no longer works and we have to reset the device. We could force it to periodically recalibrate to fix this but then we'd have the problem that sometimes the user is touching the button just as it recalibrates and that would break it for this one calibration cycle. We don't want to risk this at the moment and decided to try a mechanical button.

  We had some problems with the controller resetting randomly but that seems to come from using a lab supply instead of a real battery. Probably the long wires and current limited source cause a voltage drop that resets the controller whenever we have a large enough current spike. We might add a tall electrolytic cap in there somewhere as we have some room next to the motor inside the case.

View all 7 project logs