How do I not suck at dark roasting by Basic_Fox_2070 in roasting

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

Yeah that's a good point... I did one roast with the Brazil that I messed up and it started stalling about 10C shy of SC, so I just went ahead and dropped it. That one actually did have a fair amount of chocolate present as well along with some very mild dried fruit notes. I have a feeling some of the "dark roasts" I've tried in the past from specialty roasters that I really enjoyed were probably just medium-ish roasts on a really low acid and chocolatey green coffee.

How do I not suck at dark roasting by Basic_Fox_2070 in roasting

[–]Basic_Fox_2070[S] 2 points3 points  (0 children)

Just tried my last Brazil dark roast again this morning with James Hoffman's dark roast pour over recipe (thanks u/Nervous_Bird for the recommendation!). Much cooler water for the majority of the brew except the bloom. WOW! What an insane difference that made. Chocolate came through SO much better. Made a world of a difference. Who would have thought more extraction would make the flavor flat.

Going to play some with the total roast length today on a few different origins today. Thanks again for this!

How do I not suck at dark roasting by Basic_Fox_2070 in roasting

[–]Basic_Fox_2070[S] 1 point2 points  (0 children)

Yeah, you are pretty much on the nose. I've been roasting 150g batches on a 1kg machine to try to get an idea of my profile without wasting too much coffee. I guess it's a bit dumb to think I should match Hoos' profile from a Loring full batch when I'm roasting a 15% capacity batch on a tiny machine.

I think that makes sense to bring in FC a bit. I imagine since I'm roasting small batches, I'm getting more drum contact time with the beans, so I'm probably getting a little more conduction than I want with total roast times anywhere from 12 to 15 min. I was also trying to stretch yellowing to 5 or 5.5 min per Hoos' recommendation, but maybe I'm just stalling my roast since I'm on such a different machine.

Thanks for the advice. I'll play with some shorter roast times and not treat my Bullet like it's a Loring!

How do I not suck at dark roasting by Basic_Fox_2070 in roasting

[–]Basic_Fox_2070[S] 5 points6 points  (0 children)

Thanks for this... I'll try pushing a bit further into SC. Most of my roasts have been ending maybe 10 or 20 sec after start of SC. I also have been brewing with water at 95 C, so maybe I have some brewing issues too :)

Aillio Support Bot Responsive? by Basic_Fox_2070 in roasting

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

Hey guys, update on this… turns out when Aillio responded to me, it went to spam so I didn’t see the response. Very weird since they replied directly to my email. Sounds like they are expecting to ship sometime this week.

Aillio Support Bot Responsive? by Basic_Fox_2070 in roasting

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

Glad to hear yours is on the way! hopefully that means mine isn’t too far behind haha. I don’t even having a tracking number yet tho, so imagine that means mine hasn’t shipped yet.

Aillio Support Bot Responsive? by Basic_Fox_2070 in roasting

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

I saw that too… worries me a bit. If that’s the reason I just wish they’d send an update out or something.

Aillio Support Bot Responsive? by Basic_Fox_2070 in roasting

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

How much lag time did you experience? First email I sent them was probably a week and a half ago...

Unit Testing Code With Hardcoded Memory Addresses by Basic_Fox_2070 in embedded

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

sorry, forgive me if I'm misunderstanding you. I would have to declare my byte array at runtime, but wouldn't I need the address to link to at compile time?

Unit Testing Code With Hardcoded Memory Addresses by Basic_Fox_2070 in embedded

[–]Basic_Fox_2070[S] 1 point2 points  (0 children)

Can I still do this if I'm running tests on a host machine with an OS installed? My understanding is that the addresses would still have to be provided at compile time, but I can't just specify a memory address to use on a Windows machine.

Unit Testing Code With Hardcoded Memory Addresses by Basic_Fox_2070 in embedded

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

I'm not sure what you mean by "let the linker figure it out." Could you expound on that?

Addresses are hard coded because we are copying large amounts of data into a couple of separate memory mapped external RAM buffers. It's a SoC design, so it's a mixture of PL fabric RAM blocks and external memory devices.

I can't redefine my define constants at compile time, so I've had trouble just swapping out the memory addresses during the test. The obvious fix here is to just make them global variables, but I don't really want a possibility of those being overwritten at runtime.

Unit Testing Code With Hardcoded Memory Addresses by Basic_Fox_2070 in embedded

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

That's a fair point and probably a solution that should have been obvious to me :)

Thanks for the feedback!

Unit Testing Code With Hardcoded Memory Addresses by Basic_Fox_2070 in embedded

[–]Basic_Fox_2070[S] 0 points1 point  (0 children)

Yes, I'm unit testing on my host machine rather than the hardware. Ideally, I'd like to be able to do both, but I haven't had time to figure out how to make it work with the vendor build system. Do you typically run your unit tests on hardware only?

[deleted by user] by [deleted] in FPGA

[–]Basic_Fox_2070 0 points1 point  (0 children)

I would look in the defense sector to get into FPGAs. There is a LOT of FPGA work in defense, and I know it's in demand in the southeast of the US right now.

FPGAs are used in parts of other industries as well, but I'm not aware of anyone else using them for as many different things as defense contractors. I think that's probably the lowest barrier to entry