OSRTT Pro CS – My NEWEST Open Source Response Time Tool
|This is the new Pro CS version of my open source response time tool. I’ve been working on this one for months, and I’m incredibly excited to finally show it off properly! I should explain why this exists though, and the first clue is in the name, “CS”. That stands for “Chip Shortage”, and this whole thing is designed to solve two, or actually three big problems. The first is the part that hasn’t changed since I started making these tools. The original open source response time tool had a soldered-in Adafruit ItsyBitsy M4, and OSRTT Pro had the same board but in removable headers. As a part choice, it made perfect sense. It fitted all the project’s needs, it was widely available, and a reasonable price too. Sadly, over time those latter two points changed. Mouser, the place I get my components for the most part, stopped selling them, and I had to look elsewhere. The price also increased too. Now I just ate that cost, I didn’t want to raise the price of the tools just because the parts were getting more expensive, but in recent months they’ve become completely unavailable, at least to sole traders like me. The last three boards I bought to round out the last batch of OSRTT Pro boards came from an ebay seller in Germany for DOUBLE the original price I was paying when I started to build these tools. That’s just not sustainable, and the stock levels were pretty low there too.
So, I did the professional thing and built the microcontroller onto my board. I followed Adafruit’s schematic, and wired it up as they have. That’s important, because one of the key things about the SAMD51 – the chip both I and Adafruit use – is that they require what’s called a bootloader. A bootloader is kind of like the operating system the chip runs with. Specifically, it sets things like what each of the configurable pins do, it sets up all the clocks and internal registers, and provides the instructions that then lets you run whatever user-space program you install – in my case that’s the OSRTT code. While I did briefly consider writing my own bootloader, and I have spent far, far too much of my life reading the datasheet for this damn chip, Adafruit has done such an incredible job writing an brilliantly reliable and feature-rich solution that I’d be reinventing the wheel with a flat plane. It just didn’t make sense, so I’m using the ItsyBitsy bootloader here.
The second problem the new CS boards solve is trouble with manufacturing and reliability. In the last two batches of OSRTT Pro boards I’ve built, I’ve had a painfully high defect rate, specifically the custom digital potentiometer setup I made to control the gain on the light sensor. This is made up of eight resistors in increasing sizes, and a switch chip that effectively bypasses any combination of the resistors, allowing for the functional resistance to be modulated from around one kiloohm to 1.3 megaohms. That means no matter the display brightness, OSRTT Pro should be able to measure it. As a bit of background for why I designed my own digital potentiometer instead of using a stock one, there were two main problems there. First was the largest digital potentiometers were only rated for 1 MOhm, and that wasn’t quite enough. Second, and the more prominent issue was that after I acquired some of those rather rare 1 MOhm digital pots, I realised they have an insane tolerance. The one I tested measured at just 750 KOhms, and the actual rated tolerance was a shocking +-30%. That would mean each OSRTT Pro would have potentially swung by 60% in the resistor values, and that just wasn’t acceptable. So, I designed my own solution.
Originally I was using this MAX14662 chip which was an 8 channel switch that talked to the microcontroller over three wire SPI. That was fine, although I had trouble soldering it down – see I’ve been building these boards by hand at my desk downstairs. I don’t have a pick and place machine or soldering ovens, I have my shaky hands and a soldering iron, so to solder this tiny chip down was a pain. I decided to switch to a very similar chip, this time from Analog devices, an ADG714, which had a much easier to solder pinout. This worked fine for several batches, with only the very first test board that I had soldered and desoldered several times, and the most recent two batches, I started to have issues. Instead of the potentiometer gradually decreasing the resistance, it was just all over the place. This legitimately took me a month to fully diagnose, and genuinely had me in utter despair, not knowing why it was suddenly broken. While, even now, I’m not 100% sure, I’m pretty convinced that the PCBs themselves are at fault, and specifically the footprint of the ADG714. Maybe the pads are just a tiny bit too close, and after heating they start to slightly short or otherwise deform to the point that they are FUBAR. Either way, it turns out that happened on the newer design boards that still use that chip, so I had to redesign that part.
Now there really aren’t many 8 way switch ICs on the market, at least not in the 8 single pole, single throw switch style I need here, I’ve basically used the only two options available. Now I could go back to the MAX14662, but that just sucks to wire up, and for all I know it could be susceptible to the same PCB issue, so I opted to go a new route. An analogue route. Instead of using one digital 8 way switch chip, I’m now using TWO analogue 4 way switch chips. It takes up more room on the board AND requires eight pins from the microcontroller to control it, but luckily there are just enough pins available, and this should be a much more reliable way to control the resistance. There is also a slight advantage to using surface mount resistors, rather than the through-hole ones I was using, both in accuracy and in ease of manufacturing. That actually brings me onto the other big win here, which is that I’m now getting these boards manufactured – not completely built, I’m still hand soldering the headers for the display and the button at the top but all the surface mount parts. This is really the only way I can get the microcontroller soldered reliably, and it takes a load off of me so I can spend more time not breathing in soldering fumes and ruining my already ruined back. To be clear, every unit is still assembled, tested and validated before shipping, and having them pre-soldered will only make them more reliable.
One thing I put a lot of effort into ensuring was that this new CS version doesn’t need a different firmware file than the regular Pro. That’s good both for me as I don’t need to manage even more copies of ostensibly the same code, and it’s good for owners of these tools as it means any new features, fixes or other improvements I may get up to will instantly work on the standard Pro boards just as they would on the newer CS version. That also means there can’t be any mixup between which firmware file is needed – a mistake I learned from the jump between OG and Pro tools, and one I don’t want to make again. The new CS boards have one of their last remaining digital pins tied high via a resistor, meaning they should never mistake themselves between the standard Pro and the new CS version.
The final challenge these help with is an issue I’ve discovered in collaboration with a number of the owners of OSRTT Pro tools, especially Dominic from KitGuru who has helped an awful lot in providing data and running tests to help find this issue. Basically, in some fairly rare situations, thanks to gamma curves where down at RGB 0 to 51 there is just very little light level difference, OSRTT Pro often struggles to capture a meaningful difference, especially in the gamma table. If you are using the stock RGB 5 tolerance, but the program can barely tell the difference between RGB 0 and RGB 51, it isn’t going to be able to find what value RGB 5 is. Now to be clear, this can generally be fixed by using a steeper gamma curve, as in a lower number so instead of say Gamma 2.2 which is often default, try using 1.8. However, since I was planning on redesigning the tool anyway, I took this opportunity to not only improve the gain function, but the light sensor in general. I did an awful lot of testing with different configurations, even macgyver-ing this contraption to be able to test a higher number of photodiodes than I had designed for initially.
The biggest revelation came by mistake really. See I’ve been using OSRAM BPW34S photodiodes, specifically 5 of them on the bottom of the board. They work fine, but when it comes to manufacturing boards, single-sided manufacturing works an awful lot better, and since I’ve already moved to reverse-mount photodiodes for the latency tool, I decided to swap to them here too. I picked what I thought was the same thing from the manufacturer’s selection of parts and didn’t think much about it. The parts arrived, and besides finding that they had the same switch chip problem, I also found that the photodiode set was much more sensitive. It turns out that the version of the BPW34S that Vishay makes, the VBPW34S, or SR in this case, is considerably more sensitive. Like, 20-30% more sensitive, yet just as linear, and with a plenty high top end too. Long story short, I ended up redesigning the resistor array to better account for this higher current output, and included an extra photodiode for a total of 6 now. That means that, even on an OLED, and even on Gamma 2.6, you get some difference in the data OSRTT detects. Now I’d still recommend using the most linear gamma possible for the best results, but the aim of the Pro line in general is to be able to test at what the end-users would actually be using, so I thought it was worth putting in the extra effort to make this meet that goal as best as possible.
I do also want to make a quick note on the price of the Pro CS model, as it’s now £235. That has actually only increased relative to inflation, and it helps me keep making tools like this and it supports the development of the software and firmware that these tools use. So, if all of that sounds interesting, OSRTT Pro CS is up on OSRTT.com either outright available, or available for preorder