Werner Almesberger | 23 Feb 10:47 2015
Picon

Anelok: battery, display errors, evolution update

Assorted items:

- not to belittle the pure joy and excitement of watching paint dry,
  but monitoring a battery's epic journey towards inevitable doom is
  so much more rewarding:

  http://downloads.qi-hardware.com/people/werner/anelok/tmp/cr2032-510h.png

  So last week's drop was caused by the cold weather, not the battery
  showing first signs of weakness. Now that summerly temperatures are
  back, so is the battery voltage. To be continued ...

- then there is an ugly truth I hadn't revealed yet: sometimes, the
  display of Anelok would look like this:

  http://downloads.qi-hardware.com/people/werner/anelok/tmp/chaotic-display.jpg

  I thought that this may have been caused by timing issues in the
  communication between MCU and OLED, but I was a little worried by
  me already having verified the timing some time ago without
  finding any problem - which would then suggest a more fundamental
  flaw.

  Well, while playing with the slider, I noticed that this sort of
  pattern would reproducibly occur at the same positions when
  scrolling. As we know, if you can reproduce it, you can fix it.
  So I did ...

  It turned out to be a missing sanity check in my bit blit
  function, which allowed it to attempt to draw things that were
(Continue reading)

Werner Almesberger | 14 Feb 14:35 2015
Picon

Anelok: rework plan, battery update, left-shift, Anelok in China

Just a few minor items for this week:

- I made a plan for reworking existing Anelok boards to make the
  whole system run at 3.3 V:

  http://downloads.qi-hardware.com/people/werner/anelok/tmp/boost-rework.pdf

  More details:

  https://gitorious.org/anelok/anelok/source/aeaccf8b538ae2f46c894dea5afe7037b7359ce6:doc/boost-rework/README

  This looks reasonably simple. Losing the Vsys pad isn't nice but
  not really a problem at this stage.

  In the boost-rework branch, I changed the schematics and the layout
  to reflect the modifications, and they still agree with each other.
  I haven't actually implemented the rework yet, so there may still
  be surprises, such as the idea not working at all.

- meanwhile, the battery is busy discharging and has just passed the
  300 hours mark:

  http://downloads.qi-hardware.com/people/werner/anelok/tmp/cr2032-300h.png

  Not sure if the slight drop towards the end is a first sign of
  weakness or whether this merely reflects the cooler weather of the
  last couple of days. We'll see next week or so.

  The effect of temperature is noteworthy. If we assume that the
  difference between highs and lows is about 10 K, that would mean
(Continue reading)

Werner Almesberger | 6 Feb 22:19 2015
Picon

Anelok: battery results, and problems

I made a first attempt to run Anelok from a CR2032 cell. The good
news it that this time it did at least power on :)

Further good news is that the capacitive sensor worked somewhat.
It was a bit "nervous", probably reflecting oscillations in the
supply voltage, but I'm quite happy that it responded at all,
because this means that running on battery affects
self-calibration and the thresholds only lightly.

The not so good news is that things degraded quickly afterwards,
with battery voltage rapidly declining and the resulting voltage
difference between MCU and OLED breaking communication between
the two after a minute or so.

I first suspected that the battery was just too old. It's been
sitting in a drawer for maybe five years. The expiration date is
2018, but who knows if that considers the Buenos Aires climate ?

So I set up an experiment to verify the discharge profile of the
battery (a new one, from the same batch), based on the profile
published by Energizer:

http://data.energizer.com/PDFs/cr2032.pdf

Load resistance is 15 kOhm (+/- 5%, I will measure the exact value
when the experiment is done), ambient temperature about 25-35 C.

This is what the result look like after the first ~115 hours:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/cr2032-115h.png
(Continue reading)

Werner Almesberger | 31 Jan 14:59 2015
Picon

Anelok: the art of window-making

I promised more details on keeping the paint out of the OLED window.
This is the journey so far:

The masking piece (not masterpiece)
-----------------

Exhilarated with how smoothly the CAD-to-CNC process worked in the end
for cases, I decided to also try this to solve another problem: to
keep paint from the display area. For this, I made a little piece of
acrylic the size of the OLED panel, complete with a raised base for
extra strength, and a nice little knob to handle it.

The piece snugly fit into the bezel, so it would be exactly where the
OLED will later be. Here it is, already with paint applied:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-win01-paint-mask-painted.jpg

The next picture, with the piece removed, illustrates the two things
that were wrong with this idea:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-win02-paint-mask-result.jpg

First, some pain merrily crept under it. But worst, the resulting
window is the wrong size ! There's a lot of panel around the OLED's
active area, and it doesn't look pretty enough for us to want to
put it on display:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-win03-paint-mask-case.jpg

Ewww. What was I thinking ?
(Continue reading)

Werner Almesberger | 30 Jan 08:47 2015
Picon

Anelok: fully dressed

Fresh from the workshop: Anelok in a painted case. With the LED off:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-led-off.jpg

and on:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-led-on.jpg

Note that the transparent border is quite wide on the long sides of
the case. This is because I tweaked this case for the 2014 PCB
layout. With a 2015 board, the border is 0.5 mm narrower on each
side.

Since the LED currently just shines through a hole in the paint into
the bezel (which is fairly thick at that point), there is a massive
light leak on the side:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-led-light-leak.jpg

Let's market this as a security feature :)

Alas, it seems that the OLED didn't like all the abuse it had to
endure (this board was before in the very tight 2014 case, which
bent the FPC in very nasty ways) and developed a flaw:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-row-error.jpg

It seems that two rows in the middle of the OLED somehow get
averaged. The flaw maintains its position when scrolling, and also
appears with content that does not contain the cursor, so this looks
(Continue reading)

Werner Almesberger | 27 Jan 14:33 2015
Picon

Anelok: meanwhile, making development a little easier

1) The setup menu as a developer's playground

I put a number of development-related functions into the setup
menu, and I think it's a good place for such things in general.
Here is a screenshot:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/sim-setup-20150127.png

On top, barely visible, is the right/left hand configuration. Then
there are:

- Identify: show the KL26's unique 80 bit ID, see below

- RF: show the CC2543 chip revision. This is a way to confirm that
  the chip is really here. It also checks whether rfkill is set.

- LED on/off and blink: for LED testing, mainly for simulator
  debugging, see below

- Reboot: perform a software-triggered system reset, see below

I also grew tired of always having to enter the unblocking code
and made the setup menu accessible from the login screen.

2) Simulator has LED and rfkill switch

The red dot in the screenshot is the simulated LED. It tracks LED
changes immediately, without having to go through the event loop.

The rfkill switch is toggled with "R". There is no visual feedback
(Continue reading)

Werner Almesberger | 21 Jan 17:08 2015
Picon

Anelok: next round of case parts 2/2: parts galore

With all the model fixing done, it was time to spin the mill again.
This is what came out:

Run #3:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-run3-razed.jpg

Well, that didn't go too well. The mill almost completely ground away
the ceiling of the case. This was caused by the table of my mill
flexing in the Z direction and me pushing it down a bit too firmly when
setting up the tool position, so it came up by almost 1 mm while
milling.

Not much to be done here. But what survived of the part looks good.

Run #4:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-run4-chiseled.jpg

This is the other extreme: about 1 mm of extra material were left at
the bottom. I had to use hammer and chisel to get this one out of the
acrylic block.

Was that me over-compensating for my previous mistake ? The inner
structure provides a first hint:

http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-run4-unfinished.jpg

These islands around the rondels and at the window shouldn't be there.
Except for the (tall) bezel elements, the ceiling should be completely
(Continue reading)

Werner Almesberger | 21 Jan 14:32 2015
Picon

Anelok: next round of case parts 1/2: fixing issues

First, let's quickly review the problems of the first case. I've named
it for the CNC run number, #2 (#1 would be the MDF predecessor).

1) The wall around the PCB should be 0.8 mm but looked more like 0.5 mm.

   Measurements confirmed this. Strangely, the CAD model had it at 0.8
   mm. This turned out to be a bug in the new slicer: when flipping a
   part, I reversed the Z coordinates of all the vertical facets but had
   forgotten to also reverse the Z coordinates of the horizontal facets.
   It's rather surprising that the result still looked almost right ...

2) The thick base of the right-hand rondel (the rounded rectangle
   keeping OLED and the PCBs in place) didn't support the PCB.

   This was a genuine error in the model. Easily fixed.

3) The hole for the USB receptacle was off-center.

   This turned out to be me mistaking Python for Perl. Python copied C's
   handling of division and integers. So 3 / 2 is 1, not 1.5.

4) The large silo capacitor almost didn't make it into the capacitor
   bay.

   This was caused by the differences between 2014 and 2015 boards: in
   the 2015 board the edges are 0.5 mm further out, but most of the
   components are at the same place. I took the measurements from the
   2015 layout but my board is from 2014. The model now adjusts the
   capacitor position accordingly.

(Continue reading)

Werner Almesberger | 20 Jan 00:21 2015
Picon

Anelok: the 2015 case 2/2: first impressions

I first did a trial run for the bottom part on a piece of MDF. The
result was too fuzzy to even look much like a case, which is more or
less what I expected, but it confirmed that the basics were right
and the mill wouldn't go off and drill holes into itself.

I then went straigh to acrylic and the top part. This is what the
model looks like:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-alpha-top.png

This kept the mill busy for some three hours, but the result looks
nice. Of the two 2014 boards (#1 and #2) I have made, #2 is in the
2014 case and #1 didn't have a case yet. You've already seen this
board in July/August:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/brd1-top-0818.jpg

Now it was time to cut board #1 in half and to put it into the new
top shell. This is the result:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-alpha-overview.jpg

As one can see, the main PCB does fit. It doesn't have a lot of
wiggle room, but that's intentional. Here is the vertical stacking:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/case-2015/case-2015-alpha-stacking.jpg

The display is held laterally by a raised border and the rounded
barriers (one prominently in the foreground, the other one invisible
under the PCB in the background). It hangs loosely between PCB and
the window because I haven't put anything between PCB and display to
gently push it against the case.

Then there is a rim upon which the PCB rests. This is followed by a
(Continue reading)

Ron K. Jeffries | 19 Jan 17:52 2015
Picon

Anelok stanadalone password safe use case?

This may be a really ignorant question.
If someone wishes to store e.g. passwords in anelok but only retrieve by reading the anelok display (i.e. not having anelok pump bits into an attached vua USB or someday Bluetooth) computer... is this possible?

Ron K Jeffries
805-567-4670 mobile

On Jan 19, 2015 8:14 AM, "Werner Almesberger" <werner-SEdMjqphH88fIZOOU7Yiuw@public.gmane.orgt> wrote:
So far, I made the case design with fped, by making a 2D drawing for
each layer and use some scripts to stitching the layers together
into a 2.5D model. This worked, but there are a lot of things in
such a construction process that fped isn't really designed to be
good at, and those things were therefore quite hard to do.

As an example, there are many cut-outs, either for things that need
to pass a wall (e.g., the USB receptacle) or for things that just
need space (e.g., the battery). With a proper CAD, one would make a
simple geometric model for the cut-out (e.g., a box for USB) and
then subtract it from the rest.

With fped, I had to draw the inside of the wall to the cut-out, then
a line to the outside, and then back. Then repeat it all for the
opposite side. This doesn't sound too bad, but it also means that I
couldn't use the handy macro that drew rectangles with rounded
corners, or had to "generalize" it.

So the end result was something increasingly cryptic:
https://gitorious.org/anelok/anelok/source/case/case.fpd

The model was also woefully incomplete and I didn't look forward to
tackling the trickier bits, such as the lanyard hole and some
internal cut-outs I found to be necessary.


So I decided to give FreeCAD a try. After all, it says it's nice and
parametric, just what I need. It also has a nice sketcher that lets
you "declaratively" define geometries in no time. So far, so good.

Then came the moment when I wanted to adjust some parameter, e.g.,
the diameter of the cylinder containing the lanyard hole. It let me
do that without complaining, but then all the things that depended
on that geometry were out of sync.

To make a long story short, I don't think this mechanism is useful
for non-trivial designs. There are plans to improve this, but that's
not there yet and may take a good while.


However, there is a plan B: FreeCAD can also be scripted in Python.
The workflow would now be more similar to what I had done with fped
(edit, compile, inspect, edit, ...), but I'd still have that 3D
engine of a real CAD to do things like those pesky cut-outs for me.

This approach worked and I have the script to prove it:
https://gitorious.org/anelok/anelok/source/case/case.py

It's longer than the fped script but it also does more. E.g., there
are more case details and it also generates some components, for
easier orientation.

This is what the model for the complete case currently looks like:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-case-20150114.png


What I haven't figured out yet is how to make nice automatic
measurements, like I have in fped. I could calculate points and then
place a measurement on them, but there would be no guarantee that
the calculation matches the actual geometry. Or I could pick edges
or surfaces and do measurements between them, but the process of
selecting those edges and surfaces looks a bit grueling to me.


I then had to find a way to generate toolpaths from the FreeCAD
model. FreeCAD has no toolpath generation yet (they're working on
it). Some people suggest PyCAM, but that doesn't seem to have the
ability to make the sort of precise cuts we need here. Some use
HeeksCAD, which has nice CAM support that may actually be able to do
what we need, but the workflow would be rather complicated and
error-prone.

So I wrote a slicer for 2.5D models that then produces horizontal
polygons I can feed to the tools I already used before. This is the
slicer:
http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/sfc/slicer.py

Driving my old tools with the new data also revealed a great number
of bugs. They're fixed now, so overall quality of my virtual toolbox
should have improved after this ordeal :)

Next: results from a first try.

- Werner

_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion-Vk80si+ynGqyompGagk/7iLysJ1jNyTM@public.gmane.org
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
<div>
<p dir="ltr">This may be a really ignorant question.<br>
If someone wishes to store e.g. passwords in anelok but only retrieve by reading the anelok display (i.e. not having anelok pump bits into an attached vua USB or someday Bluetooth) computer... is this possible?</p>
<p dir="ltr">Ron K Jeffries<br>
805-567-4670 mobile</p>
<div class="gmail_quote">On Jan 19, 2015 8:14 AM, "Werner Almesberger" &lt;<a href="mailto:werner@...">werner@...t</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote">So far, I made the case design with fped, by making a 2D drawing for<br>
each layer and use some scripts to stitching the layers together<br>
into a 2.5D model. This worked, but there are a lot of things in<br>
such a construction process that fped isn't really designed to be<br>
good at, and those things were therefore quite hard to do.<br><br>
As an example, there are many cut-outs, either for things that need<br>
to pass a wall (e.g., the USB receptacle) or for things that just<br>
need space (e.g., the battery). With a proper CAD, one would make a<br>
simple geometric model for the cut-out (e.g., a box for USB) and<br>
then subtract it from the rest.<br><br>
With fped, I had to draw the inside of the wall to the cut-out, then<br>
a line to the outside, and then back. Then repeat it all for the<br>
opposite side. This doesn't sound too bad, but it also means that I<br>
couldn't use the handy macro that drew rectangles with rounded<br>
corners, or had to "generalize" it.<br><br>
So the end result was something increasingly cryptic:<br><a href="https://gitorious.org/anelok/anelok/source/case/case.fpd" target="_blank">https://gitorious.org/anelok/anelok/source/case/case.fpd</a><br><br>
The model was also woefully incomplete and I didn't look forward to<br>
tackling the trickier bits, such as the lanyard hole and some<br>
internal cut-outs I found to be necessary.<br><br><br>
So I decided to give FreeCAD a try. After all, it says it's nice and<br>
parametric, just what I need. It also has a nice sketcher that lets<br>
you "declaratively" define geometries in no time. So far, so good.<br><br>
Then came the moment when I wanted to adjust some parameter, e.g.,<br>
the diameter of the cylinder containing the lanyard hole. It let me<br>
do that without complaining, but then all the things that depended<br>
on that geometry were out of sync.<br><br>
To make a long story short, I don't think this mechanism is useful<br>
for non-trivial designs. There are plans to improve this, but that's<br>
not there yet and may take a good while.<br><br><br>
However, there is a plan B: FreeCAD can also be scripted in Python.<br>
The workflow would now be more similar to what I had done with fped<br>
(edit, compile, inspect, edit, ...), but I'd still have that 3D<br>
engine of a real CAD to do things like those pesky cut-outs for me.<br><br>
This approach worked and I have the script to prove it:<br><a href="https://gitorious.org/anelok/anelok/source/case/case.py" target="_blank">https://gitorious.org/anelok/anelok/source/case/case.py</a><br><br>
It's longer than the fped script but it also does more. E.g., there<br>
are more case details and it also generates some components, for<br>
easier orientation.<br><br>
This is what the model for the complete case currently looks like:<br><a href="http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-case-20150114.png" target="_blank">http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-case-20150114.png</a><br><br><br>
What I haven't figured out yet is how to make nice automatic<br>
measurements, like I have in fped. I could calculate points and then<br>
place a measurement on them, but there would be no guarantee that<br>
the calculation matches the actual geometry. Or I could pick edges<br>
or surfaces and do measurements between them, but the process of<br>
selecting those edges and surfaces looks a bit grueling to me.<br><br><br>
I then had to find a way to generate toolpaths from the FreeCAD<br>
model. FreeCAD has no toolpath generation yet (they're working on<br>
it). Some people suggest PyCAM, but that doesn't seem to have the<br>
ability to make the sort of precise cuts we need here. Some use<br>
HeeksCAD, which has nice CAM support that may actually be able to do<br>
what we need, but the workflow would be rather complicated and<br>
error-prone.<br><br>
So I wrote a slicer for 2.5D models that then produces horizontal<br>
polygons I can feed to the tools I already used before. This is the<br>
slicer:<br><a href="http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/sfc/slicer.py" target="_blank">http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/sfc/slicer.py</a><br><br>
Driving my old tools with the new data also revealed a great number<br>
of bugs. They're fixed now, so overall quality of my virtual toolbox<br>
should have improved after this ordeal :)<br><br>
Next: results from a first try.<br><br>
- Werner<br><br>
_______________________________________________<br>
Qi Hardware Discussion List<br>
Mail to list (members only): <a href="mailto:discussion@...are.com">discussion@...</a><br>
Subscribe or Unsubscribe: <a href="http://lists.en.qi-hardware.com/mailman/listinfo/discussion" target="_blank">http://lists.en.qi-hardware.com/mailman/listinfo/discussion</a><br>
</blockquote>
</div>
</div>
Werner Almesberger | 19 Jan 17:14 2015
Picon

Anelok: the 2015 case 1/2: background

So far, I made the case design with fped, by making a 2D drawing for
each layer and use some scripts to stitching the layers together
into a 2.5D model. This worked, but there are a lot of things in
such a construction process that fped isn't really designed to be
good at, and those things were therefore quite hard to do.

As an example, there are many cut-outs, either for things that need
to pass a wall (e.g., the USB receptacle) or for things that just
need space (e.g., the battery). With a proper CAD, one would make a
simple geometric model for the cut-out (e.g., a box for USB) and
then subtract it from the rest.

With fped, I had to draw the inside of the wall to the cut-out, then
a line to the outside, and then back. Then repeat it all for the
opposite side. This doesn't sound too bad, but it also means that I
couldn't use the handy macro that drew rectangles with rounded
corners, or had to "generalize" it.

So the end result was something increasingly cryptic:
https://gitorious.org/anelok/anelok/source/case/case.fpd

The model was also woefully incomplete and I didn't look forward to
tackling the trickier bits, such as the lanyard hole and some
internal cut-outs I found to be necessary.

So I decided to give FreeCAD a try. After all, it says it's nice and
parametric, just what I need. It also has a nice sketcher that lets
you "declaratively" define geometries in no time. So far, so good.

Then came the moment when I wanted to adjust some parameter, e.g.,
the diameter of the cylinder containing the lanyard hole. It let me
do that without complaining, but then all the things that depended
on that geometry were out of sync.

To make a long story short, I don't think this mechanism is useful
for non-trivial designs. There are plans to improve this, but that's
not there yet and may take a good while.

However, there is a plan B: FreeCAD can also be scripted in Python.
The workflow would now be more similar to what I had done with fped
(edit, compile, inspect, edit, ...), but I'd still have that 3D
engine of a real CAD to do things like those pesky cut-outs for me.

This approach worked and I have the script to prove it:
https://gitorious.org/anelok/anelok/source/case/case.py

It's longer than the fped script but it also does more. E.g., there
are more case details and it also generates some components, for
easier orientation.

This is what the model for the complete case currently looks like:
http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-case-20150114.png

What I haven't figured out yet is how to make nice automatic
measurements, like I have in fped. I could calculate points and then
place a measurement on them, but there would be no guarantee that
the calculation matches the actual geometry. Or I could pick edges
or surfaces and do measurements between them, but the process of
selecting those edges and surfaces looks a bit grueling to me.

I then had to find a way to generate toolpaths from the FreeCAD
model. FreeCAD has no toolpath generation yet (they're working on
it). Some people suggest PyCAM, but that doesn't seem to have the
ability to make the sort of precise cuts we need here. Some use
HeeksCAD, which has nice CAM support that may actually be able to do
what we need, but the workflow would be rather complicated and
error-prone.

So I wrote a slicer for 2.5D models that then produces horizontal
polygons I can feed to the tools I already used before. This is the
slicer:
http://projects.qi-hardware.com/index.php/p/cae-tools/source/tree/master/sfc/slicer.py

Driving my old tools with the new data also revealed a great number
of bugs. They're fixed now, so overall quality of my virtual toolbox
should have improved after this ordeal :)

Next: results from a first try.

- Werner


Gmane