Open source f/stop enlarger timer released

[Lowly]

Hah! Yes that's why I try to keep away from computers and mains electricity - don't understand any of it.

 

[polyglot]

A new release (the "eat your own dogfood" edition now that I have my new darkroom operational) is coming soon because I've fixed a couple of bugs:
- Going into focus mode in the middle of a program or test strip no longer resets the program; that really pissed me off!
- Foot switch (or pressing the rotary encoder) is now supported by the software
- Serial communication is implemented and half-tested but the host-side program is not ready yet
- Saving to Slot 7 no longer tries to write off the end of the EEPROM (!)

I've got to do a little more testing on the serial code and will release it soon; the host program will probably be released separately later without requiring you to update the code on the timer.

First question is, I've been considered a "dependent test strip" mode which would allow you do things like test different burn options after applying a prior sequence of exposures, or to do split-grade test-strips. I'm looking for your input on how people normally approach this kind of printing to ensure my approach is not crazy.

I imagine the workflow to be:
a) do first test strip, select desired exposure
b) program that exposure
c) do dependent test strip, select desired exposure
d) program second exposure in
e) rinse & repeat steps c-d until program complete.

The intention is that a secondary exposure need not be merely a burn, it could be the second part of a split-grade print. So in step a-b you choose the magenta exposure to get a desired black then in steps c-d you select the yellow exposure to get the white point.

The idea of a dependent test strip is that you first execute the current program and then the test strip. If you're doing a strip where each part need not represent the same point on the image, the current software is sufficient - you just run the program with the whole strip uncovered and then run the test strip, either covering as you go or exposing only small areas at each step. This approach is really unwieldy for the printing approach I've been using where each test-strip tile is an exposure of the very same part of the print, so you're comparing the same image portion across all the exposure options; you need to re-run the whole prior program before each test-strip tile.

Let me know if you have any thoughts on how to approach this part of the workflow and what you'd like the timer to do. I could make the timer re-run the prior exposure before each individual tile (in dependent-individual mode) but it could be really confusing. I suspect it might be simpler for the operator, though more keypresses, to just have you run the program for each step then skip through the test strip to the appropriate point. Both approaches are quite error-prone I think; the only really good way I know of (for split-grade tests at least) is with a colour head under the direct control of the timer.

The next issue to address is that my new (and probably forever) enlarger has huge warmup-time issues (nearly 1s of deadtime at warmup) that the timer doesn't account for at the moment (a constant linear time needs to be added to each exposure). This means that (for my enlarger, and many others like it), a 2 stop base exposure and 1 stop burn is notably less exposure than a single 3-stop exposure. That makes it difficult or impossible to compute a burn sequence from test strips done in various areas of the print. Optimally, you'd do a test strip at a few critical parts of the image and use those results to compute the burn sequence; that's only possible if warmup correction is present and accurate, so I think that will be coming soon. If you have an enlarging meter that can read in stops, this is a fantastic approach. You'll need a test-wedge and a spreadsheet to compute the calibration for your enlarger+paper combination.

Next option under consideration is a "dependent burn". The timer currently assumes that all dodges/burns are with respect to the base exposure, which is great until dodge/burn areas overlap. Would you find it useful to specify that a particular burn is specific with respect to the previous program step rather than the base exposure?
For example, you could specify this program:
2 stop: base
0.5 stop: first burn
0.5 stop: second burn

Currently, that will result in a base exposure of 4s followed by two exposures of 1.657s (for a total of 5.657 = 2.5 stops) for each burn area. What you might have intended was an exposure sequence of 4s, 1.657 and 2.343s to achieve net exposures of 2, 2.5 and 3 stops respectively, i.e. assuming that the second burn was inside the first. Let me know if this is something you'd want; it will make the Edit-Program interface more complicated but I think it will more-naturally represent some very common printing manipulations.

All feedback and suggestions welcome!

 

[billdlv]

The improvements sound great. I am making the enclosure for mine right now, hopefully it will be finished soon.

The only one I don't really see myself using is the dependent burn/dodge. But your explanation makes sense and having that capability there should be good as long as the interface does not get too complicated.

 

[polyglot]

Cheers. I think I can make the dependent-burn thing easy enough - press D to toggle "dependent/relative" on each program-step in the Edit mode, which will be represented on the screen with an R by the stop-count (D currently indicates drydown correction). I'll only be supporting dependent-with-respect-to-previous initially, which means you can nest burns as deeply as you like but you couldn't (for example) burn two separate areas within a first area.

Secondly, host interface (from PC) user-interface design. Any thoughts welcome. It's Java so should run on Win/Linux/Mac as long as you have the libRXTX that comes with your Arduino dev environment.

 

[polyglot]

Version 0.4 is now released. You can download the source here.

This version of the timer software has USB/serial comms in it, so I intend to just release the host software when it's ready without needing to update the timer software again until it gets warmup correction functionality. The host software will be Java, so it should run on any Windows/Linux/OSX platform that supports Java 1.6, Arduino and the libRXTX library (which comes with the Arduino SDK).

The manual still sucks, sorry. If you get stuck using the timer, email me.

 

[Mr Man]

I would like to have a go at building one of these as I need a new timer that can handel multiexposures and am in the process of converting to f-stop printing. But could you explain why this timer can only handel 7 exposures. Is it to do with the available memory on the ATmega 328.

 

[polyglot]

It can handle 8 exposures per program (print) and can store 7 programs in the internal EEPROM. The global limit is that the mega328 EEPROM is 1kB and my code represents each exposure as 16 bytes: 14 chars of text plus 2 bytes of EV. And there's about 20 bytes of configuration data for the device as a whole, so you can't fit 8 programs of 8 exposures.

If you wanted to have more-complicated exposure programs, it'd be fairly easy to change it to support 10 exposures per program and store only 6 programs (or conversely, 6 exposures per program and 10 stored programs). Beyond that it gets messier because the code assumes a single-digit keypress while in Edit-mode to specify which exposure you're modifying, so there would be some really annoying user-interface changes required to go to something like 16 exposures/program. Do you really make more than 8 or 10 separate exposures for a single print though?

With regards to progress on the timer itself... I have a Java interface library that talks to the timer and can upload/download the EEPROM (stored print program) contents. However it has absolutely no user interface and I'm assuming other Java-hacks are pretty thin on the ground out here in analogue land so I haven't made a release. I also have some detailed plans (an XML schema) about how I want programs to be stored on a PC, so I want to release that as a complete and working whole.

The other interesting thing is that I bought a couple of light-to-frequency converters and will be playing with those with a view to adding them to the timer as enlarger-meter functionality, maybe eventually closed-loop but that's a lot more work. If you've previously bought a PCB from me it will require a small amount of rewiring though because the light meter needs to connect to a specific pin that's currently allocated. I'll probably make up a new batch of PCBs, appropriately rewired, but that is many many months away.

The limiting factor: I now have a 6-week old girl and it transpires that such things are remarkable time-sinks! Many of my projects are making little to no progress.

 

[Mr Man]

Thanks for the info. I've had a look at your code but it is a bit over my “BASIC” head. I do not have one of your PCBs I was just going to breadboard it up to see if I liked it before trying to produce a single sided PCB version. However the limiting factor is the number of exposures and I do regularly produce prints with more than ten exposures. So I have decided to write my own, rather less elegant, code. I have sacrificed some of the functionality, EEPROM storage and only one program, for the ability to have more exposures and corresponding grade information, for later implementation. I like the idea of transferring programs between pc and timer and will be looking at some way, maybe with Processing, to store and transfer .cvs files between timer and PC but I fear I may run out of memory before I achieve that, would be good to be able to write cleaner code. I will post the results here if any one is interested.

 

[polyglot]

Since mine is open source, you should feel free to use it as a starting-point; in fact you could keep the majority of the program by setting MAXEXP=60, LASTSLOT=1 (one program of up to 60 steps) and modifying it so that the rotary encoder moves between exposures instead of adjusting exposures. This should probably work (not tested):

void FstopTimer::st_edit_poll()
{
// keypad events?
if(keys.available()){
char ch=keys.readAscii();
if(isspace(ch))
return;
switch(ch){
case 'A':
// edit text
changeState(ST_EDIT_TEXT);
break;
case 'B':
// edit EV
changeState(ST_EDIT_EV);
break;
case 'C':
case 'D':
changeState(ST_MAIN);
break;
case '#':
case '*':
exec.setProgram(&current);
changeState(ST_EXEC);
break;
default:
errorBeep();
}
}

// knob events?
int rot=rotary.getDelta();
if(rot != 0){
expnum+=rot;
if(expnum < 0)
expnum=0;
if(expnum > 0)
expnum=MAXEXP-1;

current[expnum].display(disp, dispbuf, false);
}
}

If you're breadboarding, I suggest buying something like eBay items 110838610978 or 271026616035. The second thing is that my current schematic is a bit stupid because it uses the INT pins for the rotary encoder while the AVR can support state-change interrupts on nearly any pin. It would be better to move the rotary encoder (if you use one) to two of the other spare pins and keep the timer-counter pins free. That will allow you to attach a light-to-frequency probe in future for use as an enlarger meter.

 

[polyglot]

I had a hack on my code this evening to support much longer programs and the problem is that the AVR runs out of RAM, not just EEPROM. So my timer software is probably not a good starting point to extend to much longer programs unless you want to run it on a larger device, e.g. a mega2560 or similar.

 

[Mr Man]

Well thanks for providing it anyway. I could not understand your code as it was rather over my head so I had got most of the way through writing my own when you posted the hack also I was having trouble getting your code to compile from this source, there is no .pde aduino file? I copied and pasted the content of the .ino file into an Arduino sketch but it would not compile. This was about the same time I ran into the same ram problems, I was trying to store arrays of 99 exposures, I cut the arrays back to 50 exposures (enough even for me I'm sure) and is appears to be OK. I have some tweaking to do on the code to finish the V1 then I will post it. I would like to look at your code running to see how you handle dodges, something I have no provision for other than pausing the base exposure. Sorry for being so dim.

 

[polyglot]

You need to download a newer (at least 1.0) Arduino IDE. The older ones used pde files, the post-1.0 editions now call them ino files. I'm using 1.0.1 I think.

Actually I think mine would work for complex programs if I took out all the text descriptors for each step. I got it up to about 16 steps with 6 chars/step but going to no text should work with ~64 steps. How you'd remember what to do at each step though I have no idea.

If you want to see the maths behind dodging, look at the Program::compile functions. I should probably make a video sometime... but working on my print backlog is more important

 

[polyglot]

If a timer without textual labels for each exposure is useful to you, then I've managed to hack mine to support 40 exposures per program and it can save 12 programs to EEPROM. PM me your email address and I will email you the source.

 

[polyglot]

Announcement time!

Due to ongoing demand for this timer (the PCBs sold out two years ago!), I have re-designed the PCB and this evening sent off for a new batch of 20 to be manufactured. The new version has some pins broken out so that you can theoretically connect a TSL230 (much wider dynamic range, complex control scheme) or TSL235R (low max-brightness but probably OK under enlarger, may require some ND; no control logic required) light meter and therefore meter your exposures. I don't have such a meter yet (I can't find the one I bought) so there is no software support for it at this time. It should allow the timer to operate closed-loop (for cold lights), or to spot-meter your negative under the enlarger for the purpose of analysing required exposure and/or doing zone/contrast calculations for VC paper. I'll have to have a bit of a ponder about how that integrates with the core timer functionality, and suggestions re the workflow are welcome.

Boards are $10 each plus postage at-cost; I expect them to reach me in about 2 or 3 weeks. Feel free to PM or email me pre-orders and once I've tested the first one (a donation to the local community darkroom), I will contact you about payment (PayPal).


In semi-related matters for those who are hacking on enlargers, have you seen the new 100W LED chips? They're about $10, or $15-20 with the supply controller. Craziness.

 

[polyglot]

Revision-B boards have arrived and I will hopefully get to test one this weekend. Thanks to the 5 people who have PM'd me their orders, you'll hear back soon once I have the first board running.

 

[Dr Croubie]

Yeah, chuck me down for one of them too, I could do with something better than an iphone app set to a 1s metronome 'beep'. I'll get it off you whenever the next meetup is...

 

[polyglot]

First two boards are assembled and tested; the new layout works. I haven't tested the TSL235 functionality because I still can't find the one I bought.

Postage costs are:
- Australia: $1, or $5 registered (1-3 days)
- International*: $7 airmail (3-14 days), $15 registered (3-14 days), $16 express (3-7 days, untracked), $25 (tracked)

... plus $10 per board, pay via PayPal. If you want to buy multiple boards, there will be little or no saving on postage unless you buy 4+ because a single board can go as a letter (cheap!).

When paying, make sure your postal address is included in the PayPal transaction! If you've PM'd me, you have a board allocated for sure, and there's about 10 left after the PMs. If you've PM'd me, you should have received a reply recently linking to this post and with my paypal address included. Let me know if you didn't.

I haven't yet uploaded the new code for the different pinout to my website but should do so in the next few days - before any boards arrive. If you're building a timer using the new board, make sure you get the latest code, it will have a 2014 date on it. The new code will also work with the old boards (but no TSL235 support!) if you set the preprocessor directives appropriately.

* I checked postage prices to USA, UK, CA, FR, IE, NO and they're all identical. If you're in the western world, these prices are probably valid. You can also see for yourself on auspost.com.au.

 

[polyglot]

PS for those who are using the original board and want light-sensor capabilities, the new board is mostly footprint-compatible. I have already replaced the board in my timer without making ANY hardware changes, because everything stacks up identically. Assuming I get the TSL235 integrated with the timer software, you can just buy a new board to replace your old one with no need to replace any other major components (arduino, LCD, keypad, relays, etc). You'll need to reprogram the arduino with the new software of course.

Again, this is open software/hardware. If you want to build your own, you can. You don't need to buy a board from me, you can make one of these using a $3 prototype shield and an hour with your soldering iron. I still recommend the use of a powerswitchtail for those who are not trained as electricians or electrical engineers, just for safety reasons.

 

[fran]

paypalled just now. I sent US dollars? I know you're in oz but I thought maybe you went for USD as most things around here are in USD. If there's any shortfall, just let me know.

Will pm you my address in case you can#t get it off paypal.


Lastly, if you have it handy, would you post a BOM - or a screenshot of a mouser/farnell basket etc?

Cheers, and many thanks for making this happen.


Fran

 

[polyglot]

Thanks. AUD or USD are fine.

 

[polyglot]

Payments are rolling in - too many to PM you individually now 'cos I'm lazy. I'll PM you all with a photo of your board(s) in an envelope when they go out though.

I have also updated the website (link in my signature) with the latest code, board design files, schematic, better build instructions (photos not updated though sorry) and a detailed BOM. Note that reading the detailed BOM is hellishly confusing because there are so many options re power supply and output device, so there are a LOT of optional components. Email me if you get stuck!

The manual also needs re-vamping. It's not wrong per se, just waffly and crap because it needs to cover some basic concepts, plus the fiddly details of which buttons do what. It should however have all the information in it that you need - let me know if something in there is confusing and/or the timer itself doesn't (seem to) do what the manual says it should.

Edit; phone-photos of the new boards:

 

[polyglot]

PCBs are shipped and I've emailed everyone a photo of their addressed envelope. Can you please post here if/when your boards arrive? And let us know how you go with building them?

If you've paid for a board but you don't have a "PCB shipped" email from me then something is wrong and you should contact me.

 

[fran]

My PCB landed safe and sound in Ireland today.

Now on to ordering parts and assembly!!


Fran

 

[fran]

I thought I'd share a CSV file for farnell - its handy to have part numbers etc.

Now the but - I've left a few of the parts off. No mains supply parts (assuming almost everyone will use a 5V usb charger). Also no relay included as these are pretty dear in farnell and you'd be better off getting that from ebay etc. No other hardware either - the case, standoffs and so on. The keypad shown doesn't have the alpha chars printed on the keys - I couldn't find any in farnell. Other than that I think it should be OK.

Always check it before using in case I've missed something, I hope its useful.


Fran

 

[mexipike]

Are there any boards still available? I still have the older model but I feel I may become antiquated!

Also, if anyone who receives one and is building his timer will help out with some construction pics or video it would be awesome! I'm a noob on this and have been sitting on an unused PCB and arduino uno reluctant to try and make it work. With the new update on the site I, starting to feel a little more brave.