Blog

Defrosting the Blog – Kelvin Dropper

Hi Reader,

Wow it’s been a while. In 2017 I took on too many contracts at once and totally lost control of my time. Once I fell out of the habit of posting in the blog, the barrier to posting again became progressively higher, because there was more and more to catch up on. In the interest of getting back into the habit, there’s going to be a pretty radical tone shift. In addition to Mooshimeter support, I’ll be writing about whatever I’m working on and allowed to talk about, or just projects that I suspect you would find interesting.  So as a way of saying

Long Time No See!

I’m going to talk about a personal interest project I built in December of 2016 but never wrote up. The device is called a Kelvin Dropper. It’s a high voltage electric generator powered by falling water. They have no moving parts except for the water itself (although I built mine with a water pump for continuous use).

The electrical generation is pretty neat, but it was the behavior of the charged water that I wanted to emphasize because it’s beautiful. Watch the video below – it’s in slow motion to make the droplets easier to follow. They’re going into decaying circular and spiral orbits around the wires.

So what’s going on? The droplets are charged to a high voltage, as are the rings they are passing through. They are charged with opposite polarity, creating an electrostatic attraction. You can achieve similar effects with a charged balloon.

But how does the moving water separate the charge? The Wikipedia article explains it in better detail than I will here. But basically you arrange two electrodes so they induce opposite charge on two streams of water, which is then harvested by the other electrode, creating a positive feedback loop.

How make it?

There are two big gotchas constructing this device.

The first is that the voltages are very high but the currents are vanishingly small, meaning charge leakage is a huge issue. You have to be really careful in your construction and stick to plastics wherever possible.  I built this out of PVC and fishing line because they’re both excellent insulators.

The second is that you need to have good control over where the stream of water separates into droplets. I played around with a couple different emitter configurations and found that a smooth, laminar flow with carefully controlled pressure was the only way to get good behavior.  The stream needs to separate into droplets right above the electrode.  The amount of charge doesn’t change significantly once it’s disconnected from the stream because it’s airborne with no path for current to flow, so you want it to separate at the point of maximum induced electrostatic charge.

The final construction that worked well for me was PVC pipe, fishing line, plastic funnels and wire. I used a cheap fountain pump powered by 4 AA batteries with a surplus elevator button to control it. For pressure regulation I built in an overflow pipe with adjustable height.  The overflow pipe is important because it makes the pressure at the emitters insensitive to the vagaries of your pump and batteries.  The emitters were roughly 1mm holes drilled directly into the wall of the PVC.  The edges of this hole are very important to get smooth flow – since they were near the end of the PVC pipes I was able to deburr them from the inside before putting the end caps on.  I chamfered them from the outside until the flows looked even.

I did another quick video that shows the whole device a little more clearly as well.

These pictures are bad, why can’t you take new ones?

Because I am a dunce and lost this machine.  Mooshim Engineering had to move offices this year and my Kelvin Dropper disappeared at some point, I think it got thrown out in the move.  So I’m digging through the pictures I took when I constructed it, and it turns out I didn’t take many.

Anyway, if you want a fun weekend physics project that doesn’t require anything beyond hand tools, build this and send me a picture!  Hope you find this post useful.

~James

5 Responses to “Defrosting the Blog – Kelvin Dropper”

  1. Manfred March 11, 2018 at 11:23 pm #

    Nice that you reanimate your blog after more than one year – but less nice, HOW you do it. The long break suggested kinda lost interest in the mooshimeter project – and the thematic focus of this new blog post now seems to confirm that! No word regarding open questions, unanswered mails, forum postings and (maybe) bug reports, no word regarding the future roadmap of the mooshimeter project and long-promised enhancements, instead “playing around” with a physical effect, which, though interesting, has nothing to do with what your customers are waiting for.

    I was always a highly motivated blog reader and enjoyed your presence and transparency, but that times seem to be over. I fear that THIS blog post after a very long pause is a very fatal signal to all (current or potential) customers which possibly reveals more than probably intended.

    By the way, a few days ago I wrote a longer forum posting regarding android bluetooth connection problems and how they could be fixed in my case. This posting existed only for a short time, then it disappeared for unknown reasons, although it is still linked from the forum overview page. (Forum bug or intended deletion???) I wrote you a mail about that, but got no answer.

    • James March 12, 2018 at 5:57 pm #

      Hi Manfred,

      First – I’m really sorry if you’ve sent emails that are unanswered, I thought I had answered all. Please re-send, I may not have received them.

      Though I stopped blogging about it, I have been providing continuous support for the Mooshimeter. There were many bug fixes and app releases in 2017 even though I didn’t write blog posts for all of them.

      I’m sorry you don’t like the way I re-opened the blog, but I do much more than just the Mooshimeter and I’d like to share.

      The Mooshimeter is pretty stable, so there’s not so much to write about it. I have started schematic work on a new version of the Mooshimeter and will write about that when I have something concrete to show. I think I’ve taken the present hardware as far as it can go and need to start again. Something with physical buttons, and that doesn’t rely on BLE, whose buggy iOS and Android implementations have been a thorn in my side for 4 years now.

      Actually you’ve given me an idea for another blog post. I will try to sketch out some of my thoughts for a new version later this week.

      Thank you for being a reader and a customer! Best,
      ~James

  2. Manfred March 13, 2018 at 12:20 am #

    Hi James,

    thank you very much for your benevolent reception of my critical blog posting!

    With “unanswerd mails” I didn’t mean own, but had some related forum complaints in mind (maybe they are all satisfied in the meantime). And yes, I agree that the mooshimeter is pretty stable. After stumbling on a way to overcome the BLE connection issues, I have no more SERIOUS problems and enjoy it so far. BUT for me it still seems kind of “unready” in some aspects.

    Some examples:

    – I’m missing such “obvious” things like being able to delete log files via bluetooth or giving them senseful names. The need of opening the case and involving a PC with card reader for this purpose is something I can live with, of course, but in my opinion it’s still a lack of expectable usability.

    – Another painful point is the missing compression of the BT file transfer which can lead to unacceptable transfer times for longer logfiles. If I remember right, you were planning to optimize the firmware in order to free enough program memory space for implementing compression. Can we still hope for that?

    – Third point is the often citizied graphical display, whose usability could be easily made much better in several aspects, I think.

    – Last but not least, I remember that the conception of broadcast intents had turned out to be “half-baked” and you were planning to completely rework it. Is this still a thing we can hope for? (Many single “feature requests” of different kinds could be covered all at once this way by being able to integrate the power of other apps.)

    Please excuse if some of these points should already have been solved in the meantime – maybe I missed some update due to the long-silent blog.

    Thanks also for sending me the text of my vanished posting – I will try to post it again.

    Best regards,

    Manfred

    • James March 20, 2018 at 12:48 pm #

      Hi Manfred,

      Sorry for delayed response. Regarding unanswered email – I think the thread you were referring to with unanswered email actually resolved very well after the initial missed communication.

      – I’m missing such “obvious” things like being able to delete log files via bluetooth or giving them senseful names. The need of opening the case and involving a PC with card reader for this purpose is something I can live with, of course, but in my opinion it’s still a lack of expectable usability.

      – Another painful point is the missing compression of the BT file transfer which can lead to unacceptable transfer times for longer logfiles. If I remember right, you were planning to optimize the firmware in order to free enough program memory space for implementing compression. Can we still hope for that?

      I hear this. I originally decided not to allow remote deletion because the log files are so relatively small compared to SD card capacity and I didn’t want to allow random passers by to delete long running logging experiments. But the main impediment now to deletion and compression features is actually just a lack of firmware space. The CC2540 can hold 256kB of program. About 90k is dedicated to the bootloader, and ~70k to TI’s bluetooth libraries, leaving me about 100kB for all the other functionality. It’s packed to the point where adding anything new requires deleting or refactoring something old. This is the reason even new Mooshimeters need a firmware update out of the box – the most recent firmware doesn’t have space for the calibration code that runs in the factory, so the image flashed at the factory needs to be the older version with some logging features missing.

      These issues can of course be overcome, but the effort gets higher with each new feature. The CC2540 is an outdated chip at this point and BLE has not matured like I hoped it would over the last few years (libraries from major vendors still riddled with bugs). I’m investing more time into designing a new product with what I’ve learned. I’m planning on building around the ESP32, which should offer much faster transfers (it can connect through BLE, regular bluetooth, or wifi). So right now I have plans on improving the apps but probably won’t touch the firmware unless something show-stopping comes up (like another iOS/Android update that ruins compatibility).

      – Third point is the often citizied graphical display, whose usability could be easily made much better in several aspects, I think.

      I welcome suggestions and have merged in several open source contributions on github (code is here: github.com/mooshim). Generally my design philosophy is “function over form”.

      – Last but not least, I remember that the conception of broadcast intents had turned out to be “half-baked” and you were planning to completely rework it. Is this still a thing we can hope for? (Many single “feature requests” of different kinds could be covered all at once this way by being able to integrate the power of other apps.)

      I remember this was an effort by Duane (https://github.com/DuaneOne) that I improved and merged in. Can you remind me what feature here is most needed?
      Best
      ~James

  3. Manfred March 23, 2018 at 12:03 pm #

    Hi James,

    thanks for your detailed answer!

    – Can you remind me what feature here is most needed?

    Not a specific feature; it’s more of a fundamental problem with the 2nd channel when using intents. After longer search, I re-found your posting from 2016 where you kind of promised to fix it: https://moosh.im/f/topic/broadcast-intents-how-to-use-it/#post-14739
    In short: You were planning to bundle the readings from all channels in a single intent., rather than using separate intents (which often leads to losses). How about this plan from today’s point of view?

    Regards,

    Manfred

Leave a Reply