Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
miniEngine version 2 - idea thread
#21
Hello Airic,

Another development ideea, for the "trigger" section.
(I wonder if Arduno UNO will still have enough memory space for the program :-) )

Night lightning photography.
I mean thunderstorm flash.

The traditional approach would be to put the camera on bulb, put whatever appropriate aperture and distance and trigger the camera for a certain amount of time (remember: the target is lightning photography not night/ stars photography). Usually 30 secs would be enough.
If during these 30sec, all Mighty God had flashed, the camera ends prematurelly it's 30sec cycle and it starts again, waiting for the next flash.

Currently, this is done by humans using a remote camera switch.

My ideea of thunderstorm flash photography section would be:

Input parameters:
- duration of the "camera_shoot" time.
- offset adjustment of the light sensor (in order not to trigger end of "camera_shoot" at every little spark)
- duration of the "pause between shots" in case the camera has the NoiseRemoval function activated (which will take another shot with curtain's closed in order to detect the hot pixels) + a couple of ms that will estimate the saving to card time


This function does not necessary require a "number of cycles" input parameter.



In any case, it's up to you how many (further) functions you want to implement in this new miniE.
It's a trade off between simplicity and versatility.
Reply
#22
(05-22-2013, 12:38 PM)alexella Wrote: Another development ideea, for the "trigger" section.

cool Smile

(05-22-2013, 12:38 PM)alexella Wrote: (I wonder if Arduno UNO will still have enough memory space for the program :-) )

The next version will still be based on the DUE - NOT the UNO!
...and the reason is because there is no flash space left in the UNO - this little mate is is already fully packed with the current system.

(05-22-2013, 12:38 PM)alexella Wrote: My ideea of thunderstorm flash photography section would be:

Input parameters:
- duration of the "camera_shoot" time.
- offset adjustment of the light sensor (in order not to trigger end of "camera_shoot" at every little spark)
- duration of the "pause between shots" in case the camera has the NoiseRemoval function activated (which will take another shot with curtain's closed in order to detect the hot pixels) + a couple of ms that will estimate the saving to card time

Thus there will be an external input for triggering the camera one could implement such a solution. The Camera duration can be set in the camera as well as in the miniE (even in the current version). The sensor offset would be a simple potentiometer connected to the light sensor. This external setup would then be connected to the external-input port of the system. The duration between the shots is also already implemented and called "Camera post delay".

So - this will be possible Wink

Airic
Reply
#23
(05-22-2013, 12:36 PM)Airic Lenz Wrote: Nope (unless you are talking about the Arduino DUE)

A.

Yes i am talking about the Arduino DUE
Reply
#24
(05-23-2013, 08:21 AM)johanvd Wrote: Yes i am talking about the Arduino DUE

The schematics of the due are freely available - the shield is not done yet - so there are no schematics available at the moment. I really want to test stuff like this before making it public.

A.
Reply
#25
(05-23-2013, 11:54 AM)Airic Lenz Wrote:
(05-23-2013, 08:21 AM)johanvd Wrote: Yes i am talking about the Arduino DUE

The schematics of the due are freely available - the shield is not done yet - so there are no schematics available at the moment. I really want to test stuff like this before making it public.

A.

Okay, and thank you for the response
Reply
#26
Due?
I have a couple of Ardudino Mega 2560 laying around.
Would these also be good?

As far as I understood...they should but can you confirm?
I don't have any Due...yet... :-)
Reply
#27
(05-26-2013, 08:12 AM)alexella Wrote: As far as I understood...they should but can you confirm?
I don't have any Due...yet... :-)

Hello, in theory they should BUT (and this isa big but) I will use some features of the Arduino DUE which the Mega doesn't have - for example the possibility to have interrupts on all pins. I'll also need the extra power fo being able to control more than one motor at a time (plus driving the display which needs much more information:

16 character (= 16 byte) vs. 320 x 24 pixels x 16bit = 153,600 byte

This is approx. 10,000 times more information required for a full screen refresh! The 16 MHz of the older Arduinos wont really be able to do this in a reasonable speed without heavy code optimization. ...and in the end nothing of their computing-power would be left for things like motor control Wink

Cheers,
A.
Reply
#28
As far as I'm concerned, one missing information from many of the camera triggers I saw (but not ALL of them) is the...battery indicator.

I really want to know how much time do I have before my trigger will go dead...due to battery.
I'm not necessary interested about the input voltage (before the DC regulator) but the voltage that comes to the Arduino.

My only workaround idea is to fit in the same box a cheep&small voltage meter.
But I was wondering if Arduino can assess it's own incoming power supply?
Reply
#29
(06-08-2013, 09:41 AM)alexella Wrote: But I was wondering if Arduino can assess it's own incoming power supply?

Yes it can - All Arduinos can read voltages and convert them to a digital value. The analog inputs are the way to go here. Thus these pins can read voltages from 5V to 0V (Arduino DUE 3.3V to 0V) you need to bring down the raw input voltage to a level between these limits. It would be a good idea to use precision resistors for more accuracy.

Cheers,
A.
Reply
#30
Hi Airic,

What you're doing is great, and can't wait to see the result-you can take my order now! (Seriously)

A few questions and observations

Will the Due connectors still be accessable through the display pcb?
-I mean those not covered by the display itself, may want to add some more hardware

You went for the Big Easy driver-fine, maybe consider Pololu's as they have a smaller pcb footprint and use the same 4988 chip
Will there be enough room on the driver board to fit cooling sinks (vertical)?

You mentioned torque as a reason to go for the BED, I my investigations have found out that the matching of the driver to motor amounts almost to alchemy, especially as provided motor datasheets are often incomplete or use parameters not usually seen by enthusiasts-like quoting torque at 24v and halfstepping the motor-meaning at 12v you get only 50% of the rated motor torque. Multiply the torque in gearbox, fine, but If matched to a low efficiency gearbox/spindle, you (easily) lose 50% again! In the meantime your rig gets slower and weaker! Now planning to run my NEMA 23 at the rated 24V

Do you consider using SPI as possible driver interface?

Thx and look forward to your hardware!

Coolerooney
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)