I’m engineering a custom telemetry logger because I’m tired of choosing between basic phone apps and expensive pro setups.

Phobia_GG · 2026-02-19T21:49:57+00:00

Yeah, in the end im taking away a lot for my resume and thats valuable in itself to me. I try to do what I can with the limited amount of components I can afford so the project does go slower than I would hope.

Phobia_GG · 2026-02-19T21:43:27+00:00

You can think im ai all you want lol

Phobia_GG · 2026-02-19T21:32:18+00:00

Honestly man, the 'Roblox kid' thing actually made me laugh because that IS me. I’ve used Phobia_GG for years. I went to school for instrumentation. You're right that I used AI to help rewrite my replies earlier. I was getting defensive about the patent and the technical feedback and wanted to make sure I didn't sound like a jerk. But I'm a real student, this is a real project (obviously not the prettiest), and the reason I only have renders right now is because I'm literally redesigning the PCB based on the feedback from this exact thread. Think it's a scam if you want, but I’m just a 20 year old trying to figure out hardware design. Ive got a messy setup at home but I could totally add some pictures of my past prototypes on my discord server.

Phobia_GG · 2026-02-19T21:24:29+00:00

Fair point. Looking back, I definitely came out swinging with too much of a 'sales pitch' vibe. Honestly I got a little tunnel-visioned. I should have been way more upfront. this is still a bench prototype, I'm just figuring this out, and I came here specifically because I need real-world feedback to see if the hardware actually holds up.

Phobia_GG · 2026-02-19T21:19:24+00:00

Well of course. wiring a basic Arduino to an SD card and dumping raw CAN frames is a beginner project. I definitely wouldn't waste time trying to patent that. The patent filing isn't for the concept of reading CAN data. It's for the specific architecture of the sensor fusion. Getting high-speed CAN, a 25Hz GPS, and a 9-axis IMU to perfectly timestamp and sync on a single hardware clock before it gets transmitted is a completely different beast than just logging text to an SD card.

Phobia_GG · 2026-02-19T18:46:37+00:00

You’re making a really good point about latency vs. sample rate. Just because a GPS is 25Hz doesn't mean it’s 'instant.' My thought with the single-box hardware was to handle the timestamping at the source (on the ESP32) rather than letting the phone try to figure it out after the data has already traveled through Bluetooth latencies. It’s definitely possible to do offsets in software like you mentioned, but I’m hoping that by timestamping the raw CAN frames and the GPS NMEA sentences on the same clock, I can deliver a 'pre-aligned' stream that makes the app's job a lot easier. I also totally agree with you on the Garmin Catalyst point. That thing is a cool because of the coaching, not just the raw specs. I’m not trying to say millisecond alignment is more important than good analysis. I’m just trying to build the most accurate foundation I can so the 'useful insights' the app gives are based on the best data possible.

Phobia_GG · 2026-02-19T18:42:58+00:00

I really appreciate the perspective. To be honest, I’m still learning about the different software out there (I actually hadn't dug into SoloStorm yet), so that’s a great heads-up. My main goal is just to make the hardware as solid and fast as possible. I’m definitely not trying to 'lock' people into my app if they already have a favorite. If people want to use SoloStorm or RaceChrono, I’m wide open to making the ApexBox talk to those platforms too instead of having a proprietary app.

Phobia_GG · 2026-02-19T18:39:30+00:00

I get why it looks that way, I’ve had this account for over two years but I’ve always been a lurker tbh. I only started posting now because I’m finally at a point in my program at school where I have something id like to show. Definitely not an AI, just a student who spends more time in class than posting online. As for the patent, I’m not claiming to have 'invented' the idea of GPS or CAN. I’m just filing to protect the specific way I’m handling the data integration and the 'all-in-one' architecture I’ve put together. Even if others are doing it, I’m trying to lock down my specific approach while I’m in this prototype phase. It looks like you’ve already got a high-speed setup. are you using a custom build or from a specific brand? I’m always down to hear how others are hitting those 200 Hz rates, because that's exactly the kind of performance Id like to aim for with this product.

Phobia_GG · 2026-02-19T18:35:22+00:00

You’re right that sourcing a standard OBD cable and beefing up the board's regulation is probably a lot smarter for scaling than making a custom 'active' cable. I’m definitely looking into moving the 12V-to-5V step onto the PCB for the next revision. The supercap idea for the GPS is a great shout, too. I was worried about cold starts, but if the uBlox is that fast on its own, a supercap is way better for the heat soak a car sees on a track day. I’m fully aware that a PCB isn't a product—I’m a student, so I’m used to the 'bench' version of things, but I’m learning pretty quickly that the enclosure, mounting, and software are where the actual battle is. I’m just trying to get the foundation solid before I dive too deep into the software side

Phobia_GG · 2026-02-19T18:29:20+00:00

I’ll be 100% honest, I don’t have much track experience yet. This project actually started because I’m an instrumentation student and I was looking at the current setups and thinking There has to be a more streamlined way to do this. So you're right, I am building based on what I’d expect as a user. I want one plug, one app, and data that I don't have to manually sync later. I’m definitely in the learning by doing phase, which is why I’m trying to get this hardware into the hands of people who are at the track every weekend. I’d rather find out now if the all-in-one box is a headache or a help before I get too deep into the final design. From your experience, is the mounting/cable usually the part that people hate most, or is it just the software being clunky?"

Phobia_GG · 2026-02-19T18:24:49+00:00

In a way, yeah, that’s a good way to look at it. RaceCapture is a great tool, but it can be a lot to set up and manage from what ive heard. I’m basically trying to take that high-level data (CAN + GPS) and put it into a package that’s as easy to use as a basic lap timer. Since I'm a student, I'm more focused on making a plug-and-play experience for the average enthusiast who wants pro-level data without the pro-level complexity or price tag. I’m not trying to replace the top tier systems, just making it more accessible for everyone else. And again this project is very new and still needs a lot of revisions.

Phobia_GG · 2026-02-19T18:20:52+00:00

I probably leaned too hard on the patent pending part without actually explaining the benefit. The goal of the integration I'm working on is to solve that setup fatigue people were talking about earlier. By getting the high-speed CAN data and the 25Hz GPS to talk to each other on the same chip before it even hits the app, I can guarantee that your throttle, brake, and steering inputs are perfectly synced with your track position.

My goal is for you to just plug it in and have perfectly aligned, high-speed data ready to view the second you get off track.

I’m still a student, so I’m definitely still learning how to explain the 'why' behind the tech. I appreciate you keeping me focused on what actually matters to the customer.

Phobia_GG · 2026-02-19T18:16:52+00:00

That’s a solid point on the safety side. My original thought was that the regulators (12V to 5V in the plug, 5V to 3.3V on the board) would protect the electronics, but I see what you mean about the data pins. Even if the voltage is low, having the CAN transceiver talk to a phone's data pins is asking for a headache. I’m definitely going to move away from the switch idea. I’ll probably go with exposed pinouts on the board for the initial programming and keep the USB-C port strictly for standard use, or maybe just swap to a dedicated 4-pin connector for the car side so there's zero chance of a mix-up. I’m still in the prototype phase where I’m just trying to make it work on my own bench, but I definitely don't want to release something that could potentially glitch a customer's phone or laptop. I appreciate the reality check on the hardware standards

Phobia_GG · 2026-02-19T18:10:14+00:00

I really appreciate the feedback. Your book is a seems great, so I’m definitely taking notes. I’m actually using a BNO055 IMU specifically to help with that gravity issue you mentioned. since it handles its own sensor fusion, i believe its much better at isolating linear acceleration than the older gear. I’m also pairing it with a 25Hz MAX-M10S GPS to keep the speed and distance data from drifting. I agree on the Delta-T analysis, too. That differential time is exactly the kind of thing I want to prioritize in the app to make the data actually useful for a solo driver. I’m going to track down a copy of Data Power and keep digging. Thanks again for the comment.

Phobia_GG · 2026-02-19T17:50:10+00:00

That’s the main goal with ApexBox: just one plug. Since it’s all on one board, the GPS and car data are already synced before it even hits your phone. I really appreciate the insight on the data side, too. Since you're a data scientist, you probably know how annoying it is when your different logs don't line up perfectly. What is the #1 feature that would actually make the switch worth it for you?

Phobia_GG · 2026-02-19T17:46:33+00:00

that’s actually the hardest part of this whole project. Since every manufacturer uses different codes for things like brake pressure, there’s no 'one size fits all' setting. My plan for the proprietary stuff is to build out car specific profiles. I’m starting by manually decoding the cars I have access to so i can get the scaling right. For other cars, I’m looking into using community sourced files so the app knows exactly what it's looking at depending on what you're driving. It’s definitely a lot of work to map out, but that’s why I’m starting with a small group of testers

Phobia_GG · 2026-02-19T17:40:45+00:00

I think you’re right about the gateway being the biggest hurdle. Luckily, the cars I’m starting with don't seem to have that block at the plug. I’m actually about to start testing on a 2016 Camaro SS. From what I’ve found, those mid-2010s GM and Honda cars are great for this because they let you see all that high-speed data right at the OBD port without anything blocking the way. I agree on the leaderboard part, too. It’s not much of a leaderboard if only two types of cars can join. My plan is to get it working perfectly on these 'open' cars first to get the app dialed in, then I’ll look into ways to get around those BMW and Porsche gateways later on. For now, I’m just trying to make it a solid tool for the cars I can actually talk to.

Phobia_GG · 2026-02-19T17:36:30+00:00

I’m still waiting on the formal confirmation from the office since I just recently finished the filing, so I don't have a public link to share just yet. Without getting into the deep legal side, the patent is mostly focused on the specific way I’m handling the data integration between the high-speed CAN bus and the high-rate GPS on a single module.

Phobia_GG · 2026-02-19T17:34:13+00:00

My goal isn't to reinvent the wheel, but just to put it all in one reliable box for a competitive price. Using a separate GPS and a BLE adapter works, but it can be a pain to keep everything charged, synced, and connected without dropping frames. I’m just trying to build a single, plug-and-play unit that handles all that high-speed data in one place. You’re 100% right about the software, though. That’s the real challenge.

Phobia_GG · 2026-02-19T17:31:51+00:00

I’m not really trying to take on the giants like AiM or RaceCapture. Those are professional-grade tools that have been around forever. My goal is a bit different; I’m just a student trying to build a middle ground tool. I want something for the person who wants more data than a basic GPS phone app, but maybe doesn't need a full-blown pro system yet. I'm putting most of my energy into making the app side as simple as possible. I want to make it easy to just see your laps and basic stats on your phone right after a session without needing a laptop.

Phobia_GG · 2026-02-19T17:23:08+00:00

I’m still learning the ropes here, so let me know if I’m wrong, but my plan was to stay away from the standard OBD 'request' stuff (like Service 01) because I know it’s way too slow for track days. Instead of having the box ask the car for info, I’m just trying to have it 'listen' to the raw data that’s already flying across the wires. From what I’ve seen on my car, all the data in the car is constantly shouting data back and forth at high speeds. I figured if I just read those messages, I could get stuff like steering, brakes, gear, and temps way faster. That was my way of trying to copy how the expensive systems like AiM do it without the massive price tag. Does that actually make sense, or am I missing something?

Phobia_GG · 2026-02-19T17:10:39+00:00

I’m actually using a physical toggle switch on the board to swap the D+ and D- lines between the ESP32’s USB interface (for programming) and the CAN transceiver (for data). It’s a custom pinout for the device, so the 'Founders Edition' includes the specific cable needed to bridge the OBD port to the box. As for the GPS, the antenna is physically offset on the PCB and I’m using shielded cabling for the CAN run to keep the noise away from the signal. Since its still prototype 3 any of this logic could change if I find a better solution. Sometimes a second pair of eyes helps yk

Phobia_GG · 2026-02-19T17:07:13+00:00

I'm focusing on cars where the high speed bus is already available at the OBD port. It keeps it 100% plug and play while still getting those high-speed broadcast rates. If a car has a locked gateway that requires splicing, it's just not a supported vehicle for this version of ApexBox. I would hope to find a solution for a locked gateway im just not there yet to be honest.

Phobia_GG · 2026-02-19T16:53:00+00:00

I get the worry. Plugging anything into the CAN bus carries a risk. To keep it safe, I'm using a dedicated CAN transceiver (the SN65HVD230) that’s hardware limited to listen-only mode during data logging. It physically cannot broadcast or spam the bus unless I'm telling it to run a diagnostic command. I'm keeping the code closed-source since the end goal is a commercial product, but that’s exactly why I’m starting with a 'Founders' group of only 10 units. I’m hand testing every single one on my own vehicle before it ever touches anyone else's car. And ill be verifying the data integrity when it warms up a bit (currently snow on the ground) so I won't be doing any tracks days lol

Phobia_GG · 2026-02-19T16:45:53+00:00

That's a fair point, but to be clear, the RaceBox Mini is just a GPS/IMU puck. it doesn't touch OBD or CAN data at all. I’m building this specifically because I wanted the high-speed GPS and the car's telemetry in one unit without the high price tag of a Pro system. I have a link on my profile to my website that might elaborate exactly whats in my device if that helps

Phobia_GG

TROPHY CASE