Posted on

December update

Greetings, carbon units. Here is an update on the development over the last couple of months. Lots is happening and this is probably going to be a bit long and no pictures. So if your brain suffers from Social Media Induced ADD, you may struggle :-)

Onboard WiFi and Remote Control

One of the most requested features is remote control of the light. Lights get put in all sorts of hard-to-get-to places and it would be very convenient to be able to control the lights remotely. But how best to do it?

What should the controller be like? Should it be a separate remote control unit? Should one of the lights act as a master able to remotely control other lights? Or should we use a tablet or phone as controller?

A dedicated remote control device would probably be the best in terms of reliability and ease of use. It could be optimised for a single task. It could also use a simple and robust radio protocol and low cost radio chips. But it would be expensive to make a separate device.

If we use  one light to control the others, we could also utilise low cost radio chips, but we would bave a challenge cramming the added functionality into the user interface. It could easily turn into menu system hell where you would have to hunt around in menus and settings screens to do the simplest things.

The last option is to use a tablet or phone as the remote controller. The advantage is that it has a big screen, touch control and you most likely already have one with you. With phones and tablets the radio alternatives are Bluetooth or WiFi. To use Bluetooth with an iPhone/iPad, we would need to put an Apple chip in each light, and, well, I don’t think that is a viable option for the time being :-) So it has to be WiFi. The awesome part is that WiFi is widespread, standardised, and WiFi access points usually has an internet connection as well. The downside is that I need to add an expensive WiFi radio chip and processor to the hardware and run a WiFi software stack. The iPhone/iPad does not support peer-to-peer networking with third party hardware, so they have to be connected to the same access point. Android don’t have those limitations, but 90% of all photogs have iPads and iPhones, so there is that.

Tiny version

Another comment is the cost, the size and the light output of the current Floyd prototype. Talking to photogs, everybody wants something different. The thing everybody agrees on is that more light, less weight and less heat is a good thing.

To test the remote control I needed a number of devices. So I designed a tiny version of the Floyd. It is small, has a knob for intensity, a knob for color temperature and a button to activate remote control. If you press the button, you control the light from your iPhone, else you  control the light with the two knobs. It can be reasonably inexpensive to manufacture.

The current state of affairs is that the hardware works, there is WiFi communication between the PC and the light, but there is an iPhone App to make. I’m working with Hans Olav (pronounced “Han Solo”. Get outta here Chewbacca, how awesome is that?) to get an iPhone App prototype up and running.

Communications FAIL

Earlier this year I tried to keep up on the blogging but I think that can safely be declared a FAIL by now :-) I am a slow writer. Making videos, even the very simple ones, takes even more time  and that is time taken away from development. But that have to change. I’m just not sure how. Hmmm, actually I do know how. Until this project gets more resources, I have to take time away from development to do more blogging and videos. Dang.

User Interface work

There has been a lot of comments and suggestions on the Floyd prototype and it is coming together pretty nicely. It has been simplified and made more robust during the last few months. I think it initially was a bit to “technical” for some, too much Kelvin and EV values. It is more visual now and defaults to preset values like Daylight  and Tungsten instead of 5600 and 3200. Pauric who is an awesome interaction designer is doing some work on the User Interface to simplify and clarify it further. He’s had some really cool ideas and I’m looking forward to implement the UI improvements.

Light and math

I’ve spent a lot of time working on the quality of the light itself. Processing color mathematically involves a lot of heavy duty calculations and they have to be done within a few microseconds to keep up with changes in light intensity and color. Floyd is now capable of working with and converting between several color spaces so it produces preceptually correct output when it mixes and adjusts colors. It’s kind of a mini-photoshop in there now. We’re not messing around.

Red, green and blue produces a color spectrum that has a dip around 570 nanometers, which is around yellow-orange. That is no problem when the light goes straight from the emitter and into your eyes, like it does from a screen. But it can be a concern when the light is meant to be reflected before it it enters an eye or a camera.  So I’ve experimented with mixing in additional LED emitters to add energy in the dip and see if we can get a more even spectrum. But when we add a forth or fifth emitter, we now have a underdetermined math problem. I’m not going to bore you with the details, but this is the kind of hard-to-solve math problem that involves big greek letters with little doodads both over and under. Thankfully I got a lot of help from Joriki who is a math god and can answer any question whatsoever, as long as he can do it in Algebra.

Adding emitters does improve the color rendering ability of the light. It also requires additional driver electronics, more processor power and increases the size of the device. Whether the improvement is marginal or essential is up to the individual and dependent on the shooting situation.  I’ll guess we’ll see eventually how this pans out. Is RGB sufficient as a video light or do we need RGB+?

Next up

If you think that remotely controlling video/photo lights over WiFi sounds cool, and you are a software developer, and you want to do something with it, please do get in touch at hello@riftlabs.com. I can get prototype hardware out to you (at cost).

To people who ask “when is it going to be ready?” all I can say is that it is ready when it is good enough. We’ve obviously made a ton of progress, so it is not that far away. It is ready when people say “This is has value. This is useful to me. I want one.”.

 

Posted on

Alpha version, UI demo

Coding the UI elements took way longer than I thought. Primarily because I’m really poor at estimating.

I’ve attached a video showing the progress so far. The UI is poorly organized  and very basic at the moment. Implementing nicer graphics is not going to take as much time (im my estimate :-)). What has taken time so far is implementing the underlying business logic for the UI; basic drawing routines, a declarative UI representation, viewports, display color conversion and other painful stuff.

It will take a few days to stabilise the code and then I’ll send the first unit out for alpha testing.

Next up is the new enclosure. There is still some suggestions to test and some manufacturability issues to work out, but I’ll try to get the 3D model in reasonable shape so we can machine a few samples. Those will be the basis for a beta version.

Back to work…

 

 

 

Posted on

Mid August update

Been busy, busy, busy working on the display code and, like development tends to do, it has taken more time than anticipated. Especially the setup of the new TFT LCD display was a dog. I’ve worked with a few displays and the thing they all have in common is that the manufacturer documentation on correctly initializing the display is sketchy at best.

The previous closed source graphics library is now replaced with a new one written from the ground up. The low level driver code is optimised for speed and runs ok. Actually it is not too shabby. For the font drawing and the more elaborate drawing routines, I’ve used parts from Kevin’s excellent LPC1343 code base.

There are now basic screens for power level, color temperature adjustment and filters. I’m currently coding basic logic for menu systems and changing and storing settings. I hope to make a short video next week to show the first basic UI. We’re looking forward to feedback on that!

Thanks for the awesome comments and the emails you guys are sending! As soon as the basic UI is in place I’m back to working on the enclosure implementing some of your suggestions!

Posted on

Optimizing for magic, not for price

Everybody is asking what the price is going to be for the Floyd. It is a bit early to say exactly, but let me briefly outline how we see pricing in the grand scheme of things.

There is a lot of lighting hardware out there. Most of this hardware is mature technology, development is amortized a long time ago, the tech is well understood and many manufacturers are optimizing for price. Which is another way of saying that if you want cheap gear, there is a ton of chinese knock-offs on eBay.
In many ways, it is awesome that photogs can get access to lighting gear for an unbelievably low price. But there are reason this is possible.

Fall Foliage
Fall Foliage by XKCD

Business Economics for by Dummies

When you make something you need to decide what type of product you are making and optimize for that. Say you are in the shovel-making business. Are you making inexpensive shovels? Then you need to use cheap materials that might break more easily. You need to reduce cost of production by lowering the number of parts and operations, e.g use pressfit instead of screws, etc.

By offering a less expensive product you will typically sell more. But if your product is in demand, someone else will soon undercut you, and you find yourself looking for more ways to cut cost. You can see where this is going. Quality, customer support, innovation, all goes out the window in a race to the bottom. In a super-transparent worldwide market you soon find yourself operating on 2% profit margin. But if you sell a shitload of shovels, maybe you are fine with that.

If, on the other hand, you are making the best shovels for some particular purpose, you don’t look for the cheapest materials. You look for the best suited material, the lightest or strongest, or most flexible. You add reinforcements to weak areas, you spend time and effort trying to improve and better the performance of your product. Your product is not going to be the cheapest product on the market, but that is ok. And if your product is in demand, someone else will develop an even better product. Forcing you to innovate and improve again. No rest for the wicked.

As long as there is a significant difference between the “better” and the “cheap” everything is fine. People who need a better product are generally willing to pay more. People who do not need a better product, or don’t know better, will just buy the cheapest one.  I guess a good example is bicycles. There are some friggin amazing bikes out there. Not cheap. And there are super low cost alternatives. Problems arise when people don’t see much of a difference between the “cheap” and the “better” but that is a story for another time.

One major point of this (very simplified) worldview is that it is *not*  possible to optimize for price and performance at the same time. Do you use the cheapest or the best suited material or process? The cheapest and the best is very seldom the same.

What do we want to optimize for?

Around here, we are optimizing for innovation and awesomeness. Not the brightest or the smallest, or the biggest or the cheapest. We are trying to make the most interesting, the most creative, the best. We are optimizing for magic, not for price.

Affordable pricing is is definitely on our mind, we want to get this gear into the hands of as many people as possible. But to paraphrase Einstein: “Everything should be made as cheaply as possible, but not cheaper”.

Hardware, which is expensive to make, is priced at the minimum necessary to ensure the healthy growth of a sustainable business to ensure quality, support and availability of the products.*

Pricing formula

The method we use for pricing is not complicated. Take the BOM (the Bill of Materials), add a markup for us and a markup for the distributor and you have the sale price. The BOM is the cost all the mechanical components (like CNC machined front and rear enclosure, injection moulded button tops, screws, mounts), the electronics (the printed circuit board, the microprocessor, the LCD display, the LEDs, the connectors and all the rest of the electronics), the assembly of all the above, the loading of the firmware, calibration and  quality testing. Add to this the cost of any cables, power adapters and the cost of the packaging. Basically the cost of making one complete product ready to put on a shelf.

The standard pricing formula for Open Hardware is 2.6 times BOM. This allows 40% margin for us and 40% margin for distribution partners.  The margin allows for the cost of labor, sales, taxes, rent, customer support, returns and all the rest that is necessary for running a healthy business and taking care of the customer. It also allows for continued research and development, we plan to stick around for a long time.

So for those of you who wish that eBay knockoffs was even cheaper, you won’t find what you seek here. But I hope you will find some of the most awesome lighting gear around, at prices you can afford.

* The quote is from Chris Anderson, editor-in-chief of Wired.

Posted on

New suggested design

I’ve done some work on the design. The major goals were to incorporate learnings from the current prototype and to simplify.

The battery is now completely separate from the light. Every person I talk to has different requirements and different views on how to power the light. Separating out the power gives flexibility and seem to the a sensible thing to do.


The connectors are moved from the side to the back so that they don’t interfere with side-by-side mounting. This is not final. Needs more thinking.

More mounting and attachment options. Camera rigs uses 15mm rods, so accommodating the standard seem obvious. Please see the video for details:

Getting the design right, or at least reasonably close to right, takes serious effort. This is not an easy banana to peel! I’d love to hear what you think about this design.

Posted on

Progress update

I had some really nasty bugs to work out the last couple of weeks, but things are looking better now.

I’ve uploaded a brief video showing some basic functionality plus a very nifty feature for making light samples or recordings. The device can record changes in light intensity and color, store it and play it back.
The idea is that you can record, edit, play back and loop light sequences. The wavery light from a camp fire, hard strobes, flickering neon tube light etc.

The video also shows some  basic functionality like:

  • Power adjustable over 6 stops.
  • Full steps, half steps, thirds and tenths of a step. Or straight dimming.
  • Color temperature adjustable from 1850 to 15000.

It is worth noting that the output is stable over the entire range of color temperatures. The intensity does not vary when you adjust the color temperature. And vice versa, the color temperature does not vary when you adjust the intensity. (Well, it does in the video, as the device is not fully calibrated yet! :-))

Light of any color. The gamut? I guess it is easier to think about if I relate it to a known color space. Roughly speaking you can say that the gamut is a fair bit larger than sRGB, about the size of AdobeRGB.

Sorry about the shoddy video quality! Thinking I’d make it easy for myself I used an old Canon XM-1 camera, but it kept shifting to anamorphic on me. Should I keep trying top fix that with the unwilling video editing software, or should I get back to development? Hmmm.

Anyway, what do you think about the ability to record, edit, play back and loop light?

(If you are in a RSS reader and can’t see the video, you have to click trough to the site.)

Posted on

Battery placement

Click to view full size

The above image shows Floyd with the back cover and the battery cover removed.  The yellow feature is the display bed, it does tripple duty. It holds and positions the display, it centers the buttons and it works as a light guide for the indicator lights. The right side of the PCB is the high-current area. The external power input and the battery charger sits in the lower part of this area.

The lower end of the case holds the batteries. These are currently 4 LiPoly, 18650 size cells in a 2s2p configuration. The 18650 cells have some great advantages:

  • They can be had in fairly high capacity
  • They are available in a variety of chemistries
  • They are fairly inexpensive, even matched and packaged cells
  • They weigh next to nothing
  • High discharge versions are available
  • Multiple sources worldwide

A major disadvantage is that these cells are cylindrical, so they waste a lot of room.

Click to view full size

The image above shows a cut through the unit revealing the back. The batteries are pretty large. A prismatic (flat) LiPoly battery of the same capacity could be made almost half as thick, but the cost would be a lot higher. Why not use AA batteries? AA batteries would deliver less power for the same size and weight. So the battery life would be shorter. Or we would have to fit, say, 12 AA batteries making the unit bulkier and quite a bit heavier.

Click to view full size

The above cut shows a bit of the front and this view gives you a sense of how much room the electronics require. We can easily make the rest of the unit 15mm thick (5/8 in) or even less. The cylindrical batteries doubles the thickness. We have put them at the base to keep them a cool as possible, and to keep the unit thin. Attaching them to the back would make the unit lower and more stubby.

Nothing is final regarding the batteries and I don’t think we have found the right power solution just yet. Any thoughts? Hit the comments…

Posted on

ECAD from Eagle

Main PCB showing connectors, buttons and supports for display.

The fit of the prototype enclosure is fairly snug. Not mobile phone-snug, there is still 0.5mm headroom here and there… Still, we have to keep track of the height of  all components, especially under and close to buttons and the LCD display. You really need a workflow where you can check if any changes to the PCB interferes with physical hardware. We needed a way to export a 3D model of the PCB and open it in SpaceClaim.

I still use Eagle and I could not find a way to do this. So I made some changes to an old IDF export utility for Eagle originally written by Andy Neubacher. It is a few simple changes that fixes import problems. If you are using Cadsoft Eagle for PCB layout and want to export your board as a set of IDF 3.0 files, you can download the ULP here, or visit the Eagle ULP library.

IDF 3.0 is a simple format for describing the height and outline of components on your board. Don’t expect anything fancy, this is previous century technology. The newer IDF 4.0 format is much more advanced, but if all you need is to check that your enclosure fits the PCB, this may be OK.

Quick HOWTO

  • Create your board outline on layer 50.
  • In your library, draw the component outlines on layer 57 (tCad) and use the line thickness to set component height.
  • 1000 mic = 1 mm (e.g. if your grid is in mm, then a line thickness of 0.001 equals a component height of 1 mm).

More info can be found here.

Posted on

What is better, 96 or 85% efficiency?

On lab bench
Minimum power, blue emitters only. Showing no visible variation between LEDs.

 

I’ve been working on the current drivers for the LEDs and have arrived at a common (but still interesting) dilemma; is it best to choose efficiency or flexibility?

The old design was not really optimal and neither was the PCB layout. There were a number of issues with ground bounce and stray capacitance that needed sorting. So while struggling with those issues I, true to form, started messing about with additional complexity :-)

Just for the heck of it I tried a different LED array configuration with 28 rows of 4 LEDs. The idea was to see if we could get a better performance out of the drivers, and with very little tweaking I got 96% efficiency (blue and green) and 94% efficiency for red. That is certainly awesome, (although it is for optimal conditions). It means that very little battery power is lost in the drivers. Great for battery life!

The trouble is that this configuration sets the max  input voltage for an external power to around 9.5 Volt. The lower level is defined by the internal battery charger at about 8.5 Volt. So, for practical purposes we would be limited to 9 Volt external power . That is not so good. People got all sorts of obscure contraptions external battery packs and power supplies they want to use to power their gear.

Another issue with the short LED strings is that although the emitters are well matched, the variation becomes noticeable as light and dark patches on the panel at low power. This does not actually affect use that much, but it means that some emitters will burn brighter that others, and potentially burn out before their time. Not so good. So we would need current mirrors to compensate for the LED differences, but for strings of only 4 LEDs, the high loss in the current mirrors would eat up of the efficiency gain.

So, I’m back to using a 8 by 14 array (8s14p). The driver efficiency is about 85%. Still good, but certainly not in the same class as 96/94%. The advantage is that it looks like we don’t need current mirrors, small differences in LED forward voltage drop evens out nicely. And we are much more flexible on the kind of external power we can accept. Upper limit is 18 Volt. Lower limit is still about 8.5 Volt which is the cut-off voltage for the charger.

Actually, in theory it should be possible to run the light on a voltage as low as 4 Volt. The internal batteries would not charge, but you should get normal operation from the rest of the unit. I’m going to have to test that.