Welcome to Laser Pointer Forums - discuss green laser pointers, blue laser pointers, and all types of lasers

How to Register on LPF | LPF Donations

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

Last edited:





Wolfman29 said:
Also - Trevor, I wouldn't mind tackling some of the mathematics if you don't have the background for it (even though most people good at programming are also brilliant at math).
Click to expand...

Well, I feel like it shouldn't be too difficult but help is always welcome! :)

I haven't had power at my apartment for the last five days because of the storms that rolled through the Appalachians. Once I get power back I'll get a video up.

I also should have more PIC's come in this week... :D

Trevor
 
Trevor said:
Well, I feel like it shouldn't be too difficult but help is always welcome! :)

I haven't had power at my apartment for the last five days because of the storms that rolled through the Appalachians. Once I get power back I'll get a video up.

I also should have more PIC's come in this week... :D

Trevor
Click to expand...

Those storms were crazy! I am lucky enough to be away from home through it all but there are still plenty of people without power where I live.

I was driving through VA after and most gas stations were closed! If you did find an open station you had to wait in huge lines to get to a pump.
 
Wolfman29 said:
Indeed. And every laser would essentially have the exact same type of function, and it should be easily solvable given a few good results at various times. It's a simple second order differential equation, methinks.
Click to expand...

In theory its quite simple indeed - as soon as you shine a laser onto the sensor the readings over time will form a series that ends in a asymptote, and this can be predicted long before the sensor reaches that value. Practical implementation is another matter though. Especially green lasers will vary in output, throwing off the prediction mechanism.

I would suggest implementing it though, preferably with some indication on the display if the value is a prediction or an actual sensor reading (blink in the first case or something). I think the original laserbee firmware does predictive analysis as well, though i'm unsure to what degree.

As for the range and the DAC: Just leave it be then. If its limited to a maximum reading of 3800 or so, increasing that to the full 4095 adds so little range its not worthwhile to mess with - and i suppose its also close to the point where larger power levels could damage the sensors coating etc.
 
Benm said:
I think the original laserbee firmware does predictive analysis as well, though i'm unsure to what degree.
Click to expand...

Based on the response time I see with Ellipsis vs. the real firmware, I don't think it does at all.

Trevor
 
My 1D is coming today, so I should have video soon.

Relevantly, any tutorial information on how to write firmware for the LaserBee is available upon request.

Trevor
 
Despite all appearances to the contrary, this isn't dead. I've been a bit busy - by the end of today I will have shot about 13,000 photos at five sporting events over the course of the last four days. And I eat and sleep and do schoolwork sometimes too.

That being said, I'm quite proud of what I've done here. From my redesign, it seems like a lot of things in the original firmware were written downright improperly. I obviously have no way to tell since there's no way to pull the firmware off the chip (and it would be illegal to do so) - but based on performance, it's pretty obvious.

There's one remaining major chunk to get through before I want to post a video comparison of the old and new firmware, but I'm hoping I can get that done soon.

Trevor
 
Cool,

I'd love to see a shootout between the stock firmware and the one you have cooked up.

I suppose performance enhancement due to custom firmware isn't that crazy though, as it seems to work on numerous android telephones too, but those are a lot more complex and know more trade offs.

Surely i'm curious to see if you came up with a prediction algorithm that shows something near the proper power level much faster than the original does.
 
Benm said:
Cool,

I'd love to see a shootout between the stock firmware and the one you have cooked up.

I suppose performance enhancement due to custom firmware isn't that crazy though, as it seems to work on numerous android telephones too, but those are a lot more complex and know more trade offs.

Surely i'm curious to see if you came up with a prediction algorithm that shows something near the proper power level much faster than the original does.
Click to expand...

Yep - I'll post a comparison between the two.

The wonderful bit about custom firmware on this particular platform is the fact that there was so much unused processing power, even on a relatively low power chip.

A few things I've done:
  • Properly initialized the LCD
  • Better formatting of the LCD
  • User setting for backlight
  • User setting for whether or not to display the splash screen on startup
  • Automatic calibration for first-time meter calibration
  • Manual calibration if a user wishes to use the calibration constant set in their original firmware

I haven't done any sort of predictive work, because I have not made the curve adjustment that is required to account for nonlinearity of the TEC. Once I get that taken care of, I think speeding up the response time is a good next step.

All that's left to do before I'd say I have a workable beta build would be serial output and EEPROM saving of settings. EEPROM will get done today... serial, I'm not sure about. I'll need to write some Arduino code for the purpose of testing the serial output since I currently lack a computer with an RS232 port.

Curiously, Jerry chose not to use the built-in USART module of the chip. So, serial needs to be bit banged. Not a problem at all... just an interesting thing I noticed.

Eudaimonium said:
I've learned some coding in the meantime.

Need any help?
Click to expand...

I think I'm good for the moment, but thanks! :D

Trevor
 
I like that you've added a setting for removing the splash screen, when I forgot to turn on the meter and have my laser on the sensor already it's annoying to wait 5s for the splash screen to go away before I get a power reading.

The backlight setting will be handy too, when it's on it's to bright for the camera to pick up well, but when it's off it's so dark for the camera to pick up well.

Can't wait to see the final product. :D
 
ARGLaser said:
I like that you've added a setting for removing the splash screen, when I forgot to turn on the meter and have my laser on the sensor already it's annoying to wait 5s for the splash screen to go away before I get a power reading.

The backlight setting will be handy too, when it's on it's to bright for the camera to pick up well, but when it's off it's so dark for the camera to pick up well.

Can't wait to see the final product. :D
Click to expand...

...unfortunately the backlight setting is on/off. For some unknown reason, Jerry did not use a pin for the backlight that supports PWM. So that leaves us with the binary option. :(

Additionally, I tried to set up that functionality using timers, but the necessary interrupt frequency would have crippled the hardware and tended to muck about with the LCD communication.

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.

As for reprogramming: isn't it possible to use a ICSP clamp connector to reprogram the uC using any USB powered programmer?
 
You must log in or register to reply here.


Back
Top