Jump to: navigation, search

Talk:SpaceTime Helix

Revision as of 00:35, 15 January 2014 by Zeptomoon (Talk | contribs)

Talk:SpaceTime Helix

A few thoughts on the control of the helix through the internet or mobile devices

Controlling Helix

Controlling the helix will be limited to one user at the time. So there should be a timeout, which times out a user after 2 minutes. Users who want to control the helix when someone else has the controls should see a waiting timer counting down. The counter should show "there is another user controlling the helix, please wait". And another message in case there is a queue: "there are two other users before you who are waiting to control the helix".

The best is probably to use a token system. So loading generates a unique token for that interaction.

The tokens are queued and will be handled first-come-first-serve. The page probably needs javascript to keep trying every 10 seconds to get access for that token. On the page for the controlling user there should be a javascript keeping alive the token. This way, when someone does not want to use all the time, the control is freed up again. The waiting user should see the controls... but greyed out.

It would be nice to "register" users with their email address, so we can send them updates, et cetera - this way we can also keep track of how many people are playing with the helix.

  1. It would be nice, if a user can continue to play (after the two minutes have passed) if nobody else is trying to access the Helix.
  2. I don't think need to track the users. Let's respect their privacy. Is it really necessary to have statistics? If someone wants to get a newsletter, that's fine of course! zeptomoon (talk) 19:47, 18 November 2013 (EET)

Mobile UI controls

One page with sliders for speed, light, colors - all the functions on the first page.

Maybe two additional tabs.

- One for background information about the helix and links etc. - And another tab to start/stop the helix? This function should be a bit hidden. Because the helix will start/stop by itself at intervals - it is only for advanced users who want to put rings et cetera on the helix.


Control unit

Click to enlarge.

Mixer-style control unit

Items Product € each € total link
5 1~5kΩ linear poti 2 10 [1]
1 1~5kΩ 10-turn poti 7 7 [2]
1 rotary encoder 1 1 [3]
6 push-release switch 1.6 10 [4]
4 rotary switch (4 pos.)  ?  ? []
1 toggle switch (3 pos.)  ?  ? []
1 case (ca. A5 size)  ?  ? []

LED and motor driver

Items Product € each € total link
1 Arduino 10 - 30 10 - 30 [5]
5 5A constant current source 4 - 12 20 - 60 [6]
6 IRFZ44 (or other) Power MOSFET 1 - 3 6 - 18 []
1 Electronic Speed Controller 20 - 60 20 - 60 []

LED lamp

Items Product € each € total link
1 10W 1000lumen LED  ?  ? []
1 parabolic focusing lens  ?  ? []
2 Stereo phone (TRS) socket 4 8 [7]
... more later  ?  ? []


LED inter-connect cable
Phone jack cable (E-Guitar/Microphone style - stereo)
Items Product € each € total link
2 Stereo phone (TRS) plugs 3 6 [8]
0.5m 3x0.5mm² cable  ?  ? []
Controller cable
Standard FTP/UTP


Preliminary Roadmap (without dates)


  1. Simple LED brightness/frequency control with Arduino. DONE!
  2. Order and test materials:
    1. 10 high-brightness white LEDs TESTED!
    2. 3 high-brightness RGB LEDs receiver, not tested
    3. Lenses TESTED
    4. coolers TESTED
    5. current supplies TESTED!
    6. connectors
    7. lamp-cases ALFA TESTED
    8. 6 slider potentiometers (for mixer-style console)
  3. Build and test Arduino-controlled flashing circuit with current source, MOSFET, one/two/three 10W LEDs and cooler. TESTED WITH ONE 10W LED
  4. Optimize lens positioning and 3D-design the lens-holders for 3D-printing. DONE
  5. Assemble all parts and 3D-design missing LED-cooler-holders.
  6. 3D-print missing parts (lens-holders, LED-cooler holders, Arduino-case, etc.)
  7. ...?


  1. Optimize and test control software for 6 analog input channels, e.g. (other modes are possible):
    1. Brightness (White A)
    2. Brightness (White B)
    3. Brightness (Color)
    4. Color hue
    5. Blink frequency
    6. Blink duration (duty cycle / Helix width)
  2. Design serial-port (via USB) interface API.
  3. Implement serial-port (via USB) interface API on Arduino.
  4. Test API with PC via Arduino serial monitor or GTKterm.
  5. Write webUI for RaspberryPi (testing on a PC for now).
  6. Test webUI on RaspberryPi.
  7. ...?