Wishful Coding

It’s important to stay hydrated, but hard to know how much you are actually drinking. Some number of liters or cups does not easily translate to absentmindedly sipping from an oddly sized mug. There are health apps that let you manually track how much you eat and drink, but that is such a hassle. When I’m in the zone, it’s already hard to refill my cup, let alone enter it into some app.

So I made a smart cup holder that weighs my cup and keeps track of how much I drink.

This setup consists of the following parts:

• Lego cup holder (building instructions)
• load cell (TAL220)
• load cell amplifier (HX711)
• Arduino-compatible board (Teensy 3)

The basic idea is quite simple. Every time the cup is placed down, its weight is recorded. If the weight is less than the last recorded weight, the difference is assumed to be consumed by me, and added to the total. The Arduino code is indeed quite simple.

The only noteworthy part of the code was calibrating the load cell. I did this simply by taking a measuring cup and pouring 100ml of water at a time into a cup. Repeat a few times with a few different cups and determine the scale factor.

The cup holder had to go through several design iterations. The first ones had either too much friction, inconsistent weight measurement, or just weren’t structurally stable enough. The load cell is not a Lego part, so the tricky part was making the cup rest only on the load cell. I used a Technic Flex-System Hose inserted into Technic Plates, which just about align with the load cell screw holes.

Fun fact: a 1 x 2 Grille is slightly thicker than a 1 x 2 Tile. Maybe I’m imagining things, but it seems to be the difference between a tight fit or not. With normal tiles I had to insert some pieces of paper to keep it from flexing.

With the mechanical parts out of the way, I went on to displaying the information. Maybe a 7-segment display would have been the obvious choice, but I only had one digit. I do have a full colour LCD panel, but that seems overkill and distracting.

If it’s going to sit on my desk and I’m going to power it from my computer’s USB ports, I might as well display the information on my computer. A little icon should be less obtrusive than a blinky LED thing. I may have underestimated how easy it is to get USB serial data in my taskbar, but in the end it worked out.

I forked a Gnome extension that displays the status of wireless earbuds, which it reads from the log file of some daemon. All I had to do was change the icons a bit and make it read form the TTY… right? Well turns out reading a TTY from Gnome JavaScript is a bit painful because there don’t seem to be any functions to configure it. It would also randomly close and reset for some reason. In the end I shelled out to stty to set up the TTY to not block and then just get the whole contents of it. In the process I learned that a JS extension can definitely hang and crash your entire Gnome shell. Great design that.

So that’s it, right? Throw the code on Github, job done. Well, except I decided that in the name of reproducibility, I should make building instructions for the Lego cup holder. I used to sell Lego Mindstorms building instructions, so I’ve done it before… many years ago. So I installed LeoCAD and started making the model.

At first it went pretty well, but then I ran into two problems. First of all, I spilt the model into a base and a cupholder submodel. But when generating building instructions, LeoCAD just inserted the submodel as a part. The second challenge was making the flexible hoses.

I tried to open the model with LPub3D, which did render the submodel instructions, but did not show the flexible hose correctly because LeoCAD uses a non-standard format for those. Then I installed Bricklink Studio under Wine, and redid the flexible hose there. For some reason Bricklink Studio did not render the parts list in the building instructions, so I ended up going back to LPub3D to render the final building instructions. Phew!

Update: I have now hooked up my smart cupholder to InfluxDB using the tail input using the following Telegaf configuration.

[[inputs.tail]]
  files = ["/dev/ttyACM0"]

  # this avoid seeks on the tty
  from_beginning = true
  pipe = true

  # parse csv
  data_format = "csv"
  csv_column_names = ["cup present", "current weight", "last weight", "weight difference", "total consumed"]
  csv_delimiter = ";"

Imagine you’re writing a collaborative application where multiple users are editing a document at the same time. How do you resolve conflicting edits?

The YOLO solution is last-write-wins, resulting in data loss. The git/CouchDB solution is explicit conflict resolution, by asking the user or using domain-specific logic. The cool kids solution is to use a conflict-free replicated data type (CRDT), promising to never create conflicts in the first place!

A simple to understand CRDT is the add-only set. If two people add different things to a set, you simply add all the things. As long as you never remove things, you can always resolve concurrent edits.

Computer science has given use a whole set of these CRDTs, and people have built nice libraries out of them that promise that as long as you use these data structures you can have a collaborative app that never has conflicts or data loss. Perfect!

Except, the fact that they are conflict free does not mean that the resolution is what the user expected.

Imagine a collaborative drawing program. Lets keep it simple and say the drawing is an add-only set of lines. Perfect, anyone can add lines and there will never be a conflict!

So now Alice and Bob decide to draw a landscape together. Alice starts drawing happy little trees, but Bob suffers an internet glitch and goes offline for a minute. While offline he draws some big snowy mountains. When Bob comes back online, the add-only set neatly merges all their lines without conflict, resulting in a hot mess.

This is not an imaginary scenario. I was showing Mosaic to a friend, but their ad blocker blocked synchronization. He drew a nice circuit, unaware of what was already there, and when he disabled his ad blocker, this was the result. Not a single conflict, but not a functional circuit either. (it’s a band pass filter and a differential pair, in case you’re wondering)

Mosaic is not in fact using a true CRDT, rather it is using CouchDB in a way that avoids conflicts. Each component is its own document, so there aren’t conflicts unless two people try to drag the same component at the same time. There is no way to resolve that situation and let both people get what they want. CouchDB has a pretty good section on designing an application to work with replication by the way.

In short, no matter if you use a CRDT or something else, there are situations that cannot be automatically resolved in a way that is generic and does what the user expects. You cannot wish this problem away. To the user last-write-wins data loss and seamlessly-smushed-together data loss are indistinguishable. So how do you handle it?

I think CRDTs are a useful tool, but ultimately suffer from the same “wishing the problem away” attitude as last-write-wins. CouchDB has the right mentality of designing for conflict avoidance, and requiring domain-specific conflict resolution, but it is not a full solution either. As you saw with Mosaic, you can get too good at avoiding conflicts, leading to a result that is unexpected to the end user. You need to think of domain-specific solutions.

In the case of Mosaic the plan is that device-level changes are an explicit conflict that requires user review. If you change the transistor width, and I change the length, that is not something that should be resolved automatically, even though it technically could be. We have both changed the very important W/L ratio, and combining these edits would likely have the wrong result.

At the schematic level, it’s hard to tell if some changes are intentional. I don’t think you can or should capture overlapping components at the database level, and the best thing to do is offer Electrical Rule Checks(ERC) for likely mistakes, and good edit history to recover from them.

The release of the open source Skywater 130nm PDK seems to have started a flurry of activity around open source EDA tools, with several companies trying to form a business around an open source suite of chip design tools of some form. Of course this raises the question of what business model you’re going for.

As far as the licensing aspect is concerned, there are things to be said for the easier commercial adoption of permissive licensed tools and for copyleft encouraging the contribution of modifications, and enabling dual-license models.

A well known example of the latter is Qt, which is released under the GPL, so you can use it freely for open source projects, but if you want to develop a proprietary application that you don’t want to release under the GPL, you’ll have to get a commercial license.

Would such a model work for EDA tools? Unlike Qt your users are not writing software, they are making a chip, so GPL doesn’t really cover that. I’m very much not a lawyer, but my reading of the CERN Open Hardware License is that the strongly reciprocal one would do exactly that. Let me explain why.

The CERN OHL version 2, An Introduction and Explanation is a great place to get an understanding what problem it is trying to solve, and spoiler, it’s not EDA tools. It basically tries to solve issues with using GPL for hardware: hardware is not free as in beer, and not all IP blocks and components are open source.

A centerpiece of the license is that of an “available component” which can be either an open source thing, or something anyone can obtain with sufficient documentation to reproduce your thing. The goal is basically that if I write some HDL, the copyleft aspect applies to a PCB made with my HDL on it, but you don’t need to provide the source code for a resistor, anyone can just buy a resistor and download its datasheet. It’s an available component.

But when you squint a bit, the HDL->PCB copyleft mechanism is kinda similar to an EDA software->chip copyleft mechanism. But lawyers don’t “squint a bit” so we’ll have to get into the weeds to see if the exact wording makes sense for EDA software.

The excerpts below come from the full CERN Open Hardware Licence Version 2 - Strongly Reciprocal

2.1 This Licence governs the use, copying, modification, Conveying of Covered Source and Products, and the Making of Products. By exercising any right granted under this Licence, You irrevocably accept these terms and conditions.

The interesting bit here is the Making of Products. We’ll get back to the definitions in a minute, but it’s important to note that the license does not just cover modifying the source, but also using it to Make Products. Such as using EDA tools to make a chip, if these fit the definition.

Section 3 is typical copyleft stuff about modifying the Covered Source, but section 4 reads

You may Make Products, and/or Convey them, provided that You either provide each recipient with a copy of the Complete Source or ensure that each recipient is notified of the Source Location of the Complete Source. That Complete Source is Covered Source, and You must accordingly satisfy Your obligations set out in subsection 3.3. If specified in a Notice, the Product must visibly and securely display the Source Location on it or its packaging or documentation in the manner specified in that Notice.

So you can Make Products if you give the recipient the Complete Source, and the Complete Source is Covered Source. Let’s have a look at their definition.

1.3 ‘Source’ means information such as design materials or digital code which can be applied to Make or test a Product or to prepare a Product for use, Conveyance or sale, regardless of its medium or how it is expressed. It may include Notices.

So Source can be code, HDL, Spice, GDS, or any other design material.

1.4 ‘Covered Source’ means Source that is explicitly made available under this Licence.

This includes the source of our EDA tools, and the Complete Source.

1.5 ‘Product’ means any device, component, work or physical object, whether in finished or intermediate form, arising from the use, application or processing of Covered Source.

Clearly a chip is a device, that arises from the use of Covered Source, the EDA tools. But a GDS, bitstream, or netlist are also a work (in intermediate form) that arise from application of the Covered Source.

1.6 ‘Make’ means to create or configure something, whether by manufacture, assembly, compiling, loading or applying Covered Source or another Product or otherwise.

You do a thing to another thing. Specifically by applying Covered Source (EDA tools) to load or compile some source.

1.8 ‘Complete Source’ means the set of all Source necessary to Make a Product, in the preferred form for making modifications, including necessary installation and interfacing information both for the Product, and for any included Available Components. If the format is proprietary, it must also be made available in a format (if the proprietary tool can create it) which is viewable with a tool available to potential licensees and licensed under a licence approved by the Free Software Foundation or the Open Source Initiative. Complete Source need not include the Source of any Available Component, provided that You include in the Complete Source sufficient information to enable a recipient to Make or source and use the Available Component to Make the Product.

So all the stuff needed to make the chip basically, EDA tools as well as design files. Either as Source or Available Components.

With those definitions in mind, let’s look at section 4 again. Paraphrasing, you can Make a Product if you provide the recipient with the Complete Source. Expanding that, it says you can apply the Covered Source (EDA tools) to make a device (chip) or intermediate work (netlist, GDS), provided you give the recipient all the source files or available components specs necessary to do so.

Long story short, my amateur reading of all this is that if you release your EDA tools under CERN-OHL-S and your users make a chip with it, they have to make the design files available, unless they obtain a commercial license from you.