PhilD13 wrote:I like the design. It looks good overall to me and am thinking of ordering some boards from OSH to play with.
Thank you so much for the extensive feedback!
It's easiest to get sets of three from OSH Park and Ponoko. If you're willing to reimburse my costs, I could send you a single board and case.
Email me if that arrangement would suit you better.
PhilD13 wrote:Out of curiosity, did you upload gerbers or use the upload the board file option?
I uploaded the board file directly. I also shared
the project ("xmas-icetube prototype b" / "REV B" / "xmas-b") on OSH Park, so anyone can order the exact same board.
PhilD13 wrote:I take it that C11 and R9 are installed from the bottom?
Installing them from the bottom would probably work just fine, but I intended for those parts to be installed from the top in the dead space within the surrounding socket:
PhilD13 wrote:Missing a value for the ptc fuse so with the added stuff like GPS, are you planning a .250 or a .300 ptc?
I'm using the same 200 mA fuse (RXEF020) as in the original kit. But I think you're right: a larger fuse would have been a better choice. The 200 mA fuse will probably work fine with the Adafruit Ultimate GPS module, but other GPS modules might consume too much current.
I'll look into it.
PhilD13 wrote:No suggested part types (value) for the cathode supply transistors. might add those.
Good call. Those transistors are numbered PN2222 and PN2907A.
PhilD13 wrote:Since the software looks like it supports it, where is it intended to add on Maxim DS32kHz support to the board? or did I just miss that, EDIT: or is that the two pins/pads above C10 next to IC4? Would designing in a place on the bottom of the board for an soic version of the chip be practicable? As small as they are, they seem to take up a lot of real estate?
Because I couldn't fit the through-hole version of the DS32kHz on the board, I will be using a DS18B20 temperature sensor to do software temperature compensation instead. I wrote the code for that yesterday and it seems to be working okay. I expect accuracy to be comparable to the DS32kHz (fingers crossed). But the code is neither well tested nor posted to GitHub. But the code will be posted to GitHub soon under the
xmas-b branch.
If anyone is interested in why I think I can get similar accuracy with a DS18B20, just let me know: I'll post those preliminary data and explain my reasoning in another thread. Unfortunately, those data are sufficiently extensive and independent to warrant their own thread--at least in my opinion--so I don't want to discuss those here.
For those with their heart set on using the DS32kHz, the GPS holes provide access to the battery, ground, and regulator voltage. So without a GPS module, users could use those holes for the DS32kHz and glue it on the battery--just like the original
TCXO hack, but with easier solder points.
The idea of using the SOIC version on the bottom of the board did cross my mind when designing the board, but I didn't think I could make it work. I'd be delighted and amazed if someone can find a way to make it work.
PhilD13 wrote:If I eliminate R7, R8 (replace with jumpers) could ZVP2110A and ZVN2110A fets be used? I have a few laying around.
System power is already lowish due voltage drop across D2. If you think that the voltage drop across those FETs will be negligible, they might work. But I have not had good luck with FETs; they always seem to have a fair bit of drop. But, sorry... I have no experience with those particular FETs, so I just don't know.
PhilD13 wrote:The adafruit master schematic shows a 1k pullup (shown as 1.0k in value) which I think would be more sensitive when used with a photocell? So why the 10K decision in hardware/software?
The best resistor value would depend on the range of your photoresistor. For the
Adafruit CdS photoresistor, other people were
using a 10k, so I tried that. My code assumed (and still assumes) a simple linear correlation between ambient brightness (voltage from the photoresistor) and display brightness. Because a 10k worked extremely well, I never tried anything else.
PhilD13 wrote:I'm currently using a 1k with your software and it works ok, but wonder if I can optimize the code somehow for the 1k?
That should be fairly straightforward. Brightness is controlled in the display_autodim(void) function in display.c:
Code: Select all
int16_t grad_idx = (display.bright_max << 3) - (((display.photo_avg >> 8)
* ((display.bright_max - display.bright_min) << 3)) >> 8);
The grad_idx variable controls brightness, with 0 being minimum brightness and 255 being maximum brightness. The display.photo_avg variable is a running average of the photoresistor voltage and ranges from 0 (zero volts) to 65536 (system voltage); display.bright_min is the minimum brightness as set through the menus; display.bright_max is the maximum brightness as set through the menus. If grad_idx is less than zero, it will be set to 0; if grad_idx is greater than 255, it will be set to 255.
Please excuse all the bit hacking in the code above. I wrote the code that way because it converts efficiently to AVR machine language. If anyone needs a more human-readable equivalent of that line, let me know. I'll translate.
PhilD13 wrote:Would changing the 60v zener to a higher value (max 70v) help anything?
The IV-18 specifications recommend 50v with 70v as the absolute maximum. To me, that means the tube was designed for 50v, but you can go up to 70v without blowing it. So I'd actually recommend less than 60v. I'm currently using a 56v Zener diode, and the boost circuit with Zener diode drain provide a fairly consistent 52v.
But switching to a 70v diode might help get some extra life out of a well-used IV-18 tube with fading phosphors--just make sure the corresponding Schottky diode, D3, can handle 70v.
PhilD13 wrote:EDIT: On the temp sensor. If you could compensate in software for the average temp difference between inside the case and outside the case you could probably also display temp.
That is something I'd like to look into eventually. My initial tests showed that the average temperature difference is not consistent enough to gauge ambient temperature. If the inconsistency is due to something like display brightness, then I might be able to compensate for it in software. But if the inconsistency is due to air movement in the room (i.e. whether-or-not my ceiling fan was on), it might not be possible to reliably calculate room temperature. I just don't know yet... sorry!
Thank you again, PhilD13, for all the wonderful feedback!