Ellipsis LaserBee Firmware - Development updates, build notes, media, and more!

[Trevor]

I suppose that would a matter to dissolve somehwere at the very end, probably requiring some hardware modification such as adding a resistor between two pins to provide a high/low/off setting, or re-routing/bridging some pins as to connect it to a hardware-pwm capable output.

I don't have the circuit design handy, but if I recall correctly I believe there are only one or two pins that are PWM capable, and they are used for other things. I also am pretty sure most if not all pins are used.

That being said, the whole point of the project is to improve upon the platform without making any hardware modifications.

As for reprogramming: isn't it possible to use a ICSP clamp connector to reprogram the uC using any USB powered programmer?

I just pop the chip out, program it, then socket it again.

Trevor

 

[Benm]

Hehe okay, i didn't realize it was actually in a socket - hard soldering it to the board would probably make a device more tamper proof.

As for modifying the hardware: I get the idea of just making better firmware you can flash into an existing unit. However, i suppose it is also possible to build the entire thing from scratch if you wanted to - is there any component in there that is difficult to obtain apart from the sensor?

 

[Trevor]

As for modifying the hardware: I get the idea of just making better firmware you can flash into an existing unit. However, i suppose it is also possible to build the entire thing from scratch if you wanted to - is there any component in there that is difficult to obtain apart from the sensor?

Nope, everything is commonly available for a few dollars. All you need is a small, fast TEC.

Also, I posted this over in multimedia, but I've made a little comparison video with what I have so far.

( Direct link. )

Trevor

 

[spyrorocks]

Good progress Trevor, I especially like the fast boot up option.

 

[Trevor]

NOTE: All of the experimentation detailed below stayed well within normal operating conditions of the LaserBee. After I concluded, I tested to make sure the hardware was not faulty and confirmed that everything was functioning exactly as designed.

I'd originally given up on figuring out the curve adjustment for lack of a laser that could run the whole 0-1000mW range. Then I realized - I can just feed the LaserBee a low voltage signal and pretend it's coming from the TEC!

The Logic: If the LaserBee takes a non-linear voltage and corrects it, then it would also take a linear voltage and de-correct it.

The Setup: I pitted the original firmware against Ellipsis. Ellipsis is only scaling readings without a curve adjustment. The original firmware is both scaling and adjusting.

What I expected was some sort of exponential curve. What I ended up with actually changed slope several times - so I was slightly confused. After all, when I think of a "curve adjustment," I think of a mathematical formula applied to a datapoint to properly orient it.

Slight preface: I currently don't have anything that will generate a voltage of less than 65.6mV - so my graph starts there.

I went back to the areas where the slope change and collected data in a denser cluster of points, and made an interesting discovery.

There are knees in the curve. They fall between four distinct areas of the graph.

In the first part of the graph, the sampled reading is adjusted upward slightly:

In the second part of the graph, the lines basically fall perfectly on one another. This is where the 1W LaserBees are calibrated - for example, mine was calibrated at 500mW.

After the second knee in the curve, the readings are adjusted slightly downward:

And in the final part of the range, the readings are significantly adjusted downward:

I've got the exact numbers in an Excel sheet, but I don't have it handy at the moment.

So, it appears that the LaserBee does not use any sort of formula to adjust the curve - rather, it uses a few thresholds to determine what amount to add to or subtract from the reading.

I don't think that's ideal - since that's basically a linear correction to a non-linear function, but I suppose it was deemed "close enough" by the original developer...

At any rate, the important bit is now I know exactly what I need to do to make Ellipsis spit out exactly the same readings as the original LaserBee firmware!

Trevor

 

[Benm]

Interesting analysys on the input/reading curve!

It seems that the laserbee firmware applies correction for sensor non-linearity in a couple of steps. This may seem odd, but it can also be considered to be 'sufficient'. If you make a meter with 1% precision, there is no -requirement- to avoid these bumps in the curve as long as the reading stays within the margin of error.

That said, there is probably a better way out: I presume the best fitting curve for this sensor is something polynomial, probably a formula looking like this:

Reading = constant + x * voltage + y * voltage^2

The value of the constand and x have already been determined (x being proportional to the 361 calibration setting). What you need to determine is Y. Considering the construction of the sensor i suppose that Y would be a small negative number, adjusting the curve more and more below linear with increasing sensor voltage.

I suppose the only way to actually obtain Y is to measure lasers of known power, and/or use a calibrated meter to check against.

If you do have that available, but you do have tabulated data for voltage vs reading from the laserbee, you could use excel or something similar to fit a 3 factor polynomial curve that best matches the values over the working range.

Doing so would create a curve that matches the laserbee's pretty well over the whole range, but without the little jumps. It would be a really practical improvement too, since it is impossible to precisely adjust a lasers output power around these jump points with the laserbee as-is.

The downside is that it does take quite a bit of extra processing power and ram, since you'd be dealing with floats instead of integers to do the math. Is that feasible with the pic used?

 

[Trevor]

I'm gonna obnoxiously go at this line-by-line. Sorry in advance!

Interesting analysys on the input/reading curve!

Thanks.

It seems that the laserbee firmware applies correction for sensor non-linearity in a couple of steps. This may seem odd, but it can also be considered to be 'sufficient'. If you make a meter with 1% precision, there is no -requirement- to avoid these bumps in the curve as long as the reading stays within the margin of error.

Yeah - it definitely gets the job done, especially having seen graphs of the LaserBee readings vs. the readings of a professional LPM.

For such a simple system, I'm honestly pretty impressed with the accuracy.

If you do have that available, but you do have tabulated data for voltage vs reading from the laserbee, you could use excel or something similar to fit a 3 factor polynomial curve that best matches the values over the working range.

Doing so would create a curve that matches the laserbee's pretty well over the whole range, but without the little jumps. It would be a really practical improvement too, since it is impossible to precisely adjust a lasers output power around these jump points with the laserbee as-is.

I've got a better graph that more accurately defines the knees in the curve, so I think I can overlay a best fit line. I'll work on that some tomorrow.

The downside is that it does take quite a bit of extra processing power and ram, since you'd be dealing with floats instead of integers to do the math. Is that feasible with the pic used?

I do have space left. There are a few things vying for it right now:

1. The configurable output formatting. This shouldn't take a lot.
2. A differentiator to speed up response time.
3. A proper curve adjustment, as you suggest.

I'm hoping I can fit all three, but it remains to be seen if that's possible. And yes, floats are doable but the math is a bit resource intensive.

Trevor

 

[Trevor]

So, since I've got the curve adjustment done and the serial output done, I think it's time to send out some microcontrollers for people to try out.

Any LaserBee users interested?

Trevor

 

[Benm]

I see the trade off with the items left on the list - speeding up output reading would probably add much more to the user experience than creating a complicated calculation that leads to more accurate power readings.

If both don't fit the memory of the pic, i'd probably prefer the faster response speed over that last percent or so of gained accuracy. You could implement a more simple fit that does not have the 'bends' in them buy still can be done with integer math.

As far as distrubuting the firmware: unfortunately i don't have a laserbee here, but if you publish the code, i suppose anyone could flash it into a pic (i do have an icd2).

 

[Trevor]

I see the trade off with the items left on the list - speeding up output reading would probably add much more to the user experience than creating a complicated calculation that leads to more accurate power readings.

If both don't fit the memory of the pic, i'd probably prefer the faster response speed over that last percent or so of gained accuracy. You could implement a more simple fit that does not have the 'bends' in them buy still can be done with integer math.

As far as distrubuting the firmware: unfortunately i don't have a laserbee here, but if you publish the code, i suppose anyone could flash it into a pic (i do have an icd2).

The only problem I see with speeding up response time but using a stepwise adjustment is the fact that any jump in the reading will be greatly amplified. So in order to actually mathematically speed up response time, you must have a continuous curve.

So I sort of hope I have space for both. ><

Regarding firmware distribution... I don't think I'm going to be distributing code or a compiled binary. The only way I'm sharing code with Jerry is if he pays for it.

My solution: Send out PIC's for a beta test for only the cost of the PIC + shipping, and when a final release comes out, charge something like $10 for a flashed PIC, shipped. It's basically free for the end user, and I retain control of the source.

Ordinarily I'd just upload the whole project, but this is a bit of a different scenario.

EDIT: Also, +1 for being such a good sounding board for ideas.

Trevor

 

[Benm]

I understand your reasons for that. Moving chips around the world just to have them flashed seems a bit silly, but i can see how you would think your work could be reverse engineered even from the resulting assembly.

On the other hand, in the model you suggest you do not earn anything from people using your developed code, but keeping it to yourself does block others from improving upon it.

I suppose your main concern is that laserbee will run a version of ellipsis branded as its own, which could happen if you publish the source code. On the other hand, what would be the problem with that? Anyone can verify that this is the case and they accepted your firmware as being superior and hence implemented it.

As updates develop it would be very clear that you are th e one publishing them first, so the concern of laserbee of any other company runnning off with your ideas isn't that great.

If I were to bring an LPM to market, i'd happily claim that it runs ellipsis firmware, just like a smartphone is advertised to run android even when its manufacturer is not in any way involved in android development.

 

[spyrorocks]

I don't think distributing code that is used commercially by someone else as a selling point with no compensation is part of Trevor's business plan.

 

[Trevor]

I understand your reasons for that. Moving chips around the world just to have them flashed seems a bit silly, but i can see how you would think your work could be reverse engineered even from the resulting assembly.

On the other hand, in the model you suggest you do not earn anything from people using your developed code, but keeping it to yourself does block others from improving upon it.

I suppose your main concern is that laserbee will run a version of ellipsis branded as its own, which could happen if you publish the source code. On the other hand, what would be the problem with that? Anyone can verify that this is the case and they accepted your firmware as being superior and hence implemented it.

As updates develop it would be very clear that you are th e one publishing them first, so the concern of laserbee of any other company runnning off with your ideas isn't that great.

If I were to bring an LPM to market, i'd happily claim that it runs ellipsis firmware, just like a smartphone is advertised to run android even when its manufacturer is not in any way involved in android development.

Users would *never* flash the original chip that came on the LaserBee. Even though Ellipsis is better, I think it's still good to have the original firmware.

I would just flash and ship a new PIC ($2.00 or so?), with the version marked on it. I've got a bunch of them on-hand... I thought that would be the most logical way to do it.

Having had Jerry do his best to kill this project (I am not sure why, exactly), I'm not inclined to give him another built-in selling point. I'm perfectly happy to offer a third party firmware upgrade that I can prove does not damage the hardware and performs better than the original firmware.

Jerry is also perfectly welcome to link to my thread where I'm selling flashed PIC's for a nominal price.

I will not, however, offer up source code for him to improve his product line (and violate the terms of the license) without him actually purchasing the source code. If he wishes to purchase it, fine. Otherwise, Ellipsis will stay firmly a closed-source third party firmware upgrade.

I had originally planned on it being open-source, but given all the events that have transpired surrounding it... I think not.

It's like someone coming out with a big upgrade for iOS - they'd probably sell an upgrade, but they wouldn't post source code for Apple to steal.

Trevor

 

[Eudaimonium]

Simply "wishing" to use the software voids warranty?

Sounded like that.

And what if the user would save the old MCU, and buy new one, flash it, and use on existing hardware?

If anything goes wrong, they can simply replace the MCU back with original one.
(I hope, I don't remember if the stuff is soldered or socketed, but anyway) Would that void warranty?

 

[Trevor]

This disclaimer is rather misleading - so I'd like to take a moment to clear up a few points.

J.BAUER Electronics is the sole designer and manufacturer of all
the LaserBee Laser Power Meter products and is the sole owner
of all copyrights and trademarks for the LaserBee™ products and
the EagleEye™ software.

Likewise, I am the sole designer and developer of Ellipsis™, a third-party firmware that controls the LaserBee circuit. I am the holder of the copyright and trademark.

Any assertion that ownership of the LaserBee IP grants any ownership of or control over Ellipsis™ is false.

Anyone that implements/uses this unauthorized nor approved nor
tested (by J.BAUER Electronics) 3rd party hacked firmware on any
of our products will unconditionally void any Warranty and/or any
present or future Customer Service for their LaserBee product.

This is completely within the rights of Mr. Bauer to do, albeit unethical and not in the best interest of his customers.

That being said, Ellipsis™ controls the circuit in exactly the same way the original firmware does. It talks to all the components using 5V logic. It uses I2C to talk to the ADC, 5V to modulate the LCD backlight, a standardized protocol (HD44780 I believe) to talk to the backlight, and a 9600/8/N/1 5V serial signal.

The only place the warranty should logically be voided is during the phase where you de-socket the original PIC and put one in flashed with Ellipsis™, as this is physical modification of the device.

Moreover, this firmware is not "hacked" - but I'll explain that more in the next section.

This unauthorized blatant Hack of our Intellectual Property (IP) and
work product is not recognized, recommended or approved to be
used on any LaserBee product manufactured by J.BAUER Electronics.

Ellipsis is a completely original work that I wrote from scratch. All I needed to do was look at the device that I purchased to see what components connect to what microcontroller pins.

Then all I had to do was write some new code to drive the components. There was no patent or copyright violation. Any assertion thereof either stems from incomplete knowledge of intellectual property law or is a bald-faced lie.

The original firmware was not extracted or disassembled.

I hope this clears up any inaccuracies in misleading disclaimer above.

Trevor

 

[gillza]

Great job Trevor! And thank you for your reply above, very informational and to the point!