The FrogPad
A forum to get help or talk about Roastmaster…or anything else coffee.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Danny Hall

Pages: [1] 2 3 ... 25
Wish List / Re: USB-C connectivity on iPad Pro (Bullet R1)
« on: August 27, 2019, 01:56:15 PM »
Thank you - I appreciate that!! Lots of cool stuff coming in the next version...and more planned after that!!  :)

Wish List / Re: USB-C connectivity on iPad Pro (Bullet R1)
« on: August 19, 2019, 12:43:21 PM »

Thanks for the kind words. I thought the same about the Bullet, so I reached out to them last year...wanting to get that ball rolling. I've heard nothing back. That would be the first step. Afterwards, I'd need to determine if the USB C is actually a full-blown USB, or is (as per Apple's style) a watered-down USB - that only passes through certain subsets of protocols (camera, keyboard, etc.). I'm unsure at the moment - I've had my head so deep in electronics manufacturing and the next version of Roastmaster since the iPad pro hit, I haven't been able to export that path since last summer. If so, that would be very easy. If not, there would require a hardware box to receive the USB, and translate into Roastmaster's existing RBP protocol. I'm current entering manufacturing on Bluetooth hardware for thermocouples. After that is underway, I will think of designing a similar hardware device that could do the translations (for all types of roasters with USB) if Apple's USB implementation is NOT as open as I would like. After this hardware, I will be back to tie up a lot of loose of those will be trying again with the Bullet people to see if they are interested (or manning their web forms better) at that point. :)

Support / Re: Supermechanical temp probe
« on: August 05, 2019, 04:14:19 PM »
Sorry - no. I was involved with the kickstarter campaign for the BT series, anticipating adding support, but they never sent the API to me. Last we spoke it was unfinished. I've since assume they decided to keep the API private, though I don't know that for sure.

Support / Re: RDP DIY
« on: July 26, 2019, 02:08:15 PM »
Sorry - no. I've been waiting on LCD screen tooling (took forever). That was the biggest hurdle. Just got the prototypes in about a week or so ago. Working on the final boards and case production now.

Support / Re: Help With Roast Data Logging
« on: July 26, 2019, 02:05:12 PM »
Hi Gil

The easiest solution is to use K Type thermocouples with the ThermaQ Blue. You can see details here.

The ThermaQ Blue cal be purchased on the Thermoworks website here. They ship internationally.

As far as the thermocouple probes themselves, you can buy them from Thermoworks, or anywhere online. Just make sure they are K Type probes with the yellow "quick connector" on the end. I, myself, prefer shielded (ungrounded) probes, because their temperature reporting is smoother (albeit a little slower). Just make sure they are sized appropriately for your roasting chamber. Thermocouples CAN be bent for fitting, AS LONG as you do it on a radius (no sharp bends - only curves), and you don't bend within an inch or so from the tip where the actual junction is located.

Amazon is a good place to look for probes.

Wish List / Re: Go beyond 30 min “Roast”
« on: June 17, 2019, 01:56:59 PM »
No - sorry, the longest roast time is 30 minutes.

Support / Re: RDP DIY
« on: June 14, 2019, 06:12:22 PM »
Sorry to break your hope...but, it won't be. The first model will have 10 channels of data - reading much more than just temperatures. It is geared at specialty roasters and comprehensive home setups.

Down the road, I do plan on designing a light model - but at this point don't have any kind of time frame.

Wish List / Re: Development from 1st crack
« on: June 14, 2019, 01:53:59 PM »
Hi Kasper

See attached screenshot.

If you enable the HUD in the Analyzer, you'll see running tallies of the following

1: Drying Stage. This is defined by the presence of an Event, with its type set to "Drying End"
2: Ramp Stage. This is defined as the time from the Drying End Event to the First Crack (beginning of development)
3: Pyrolysis: This is defined by the presence of an Event, with its type set to "Pyrolysis"
4: Development: This is defined as the start of first crack to the end of the roast.

In this HUD, Roastmaster displays real-time tallies of each of these as
1. Duration in minutes and seconds
2. Percentage of time of the whole roast.

So, Roastmaster's Percentage of Development SHOULD correlate to the information on the link you sent, i.e. Rao's Development Time Ratio. Just keep in mind this a percentage, not a true ratio - that's a different thing altogether.

If you're interested in learning how to use events, there's some good information in this screencast.

Support / Re: RDP DIY
« on: June 14, 2019, 01:25:18 PM »
Yes - it is no small undertaking. Fun...but involved.

I don't plan on supporting any more thermistor style probes like the one in the link you sent. They are fine for kitchen use, but the internal windings tend to fail very quickly in a coffee roasting environment - and they usually don't even cover the required range for most roasters.

The only Bluetooth option at the moment is the ThermaQ Blue, until later this year when I plan to have Roastmaster branded hardware ready for purchase.

Support / Re: RDP probe unlinked/offline
« on: June 13, 2019, 06:55:18 PM »
Great news!

Glad you got it fixed - you're very welcome!!

Support / Re: RDP probe unlinked/offline
« on: June 13, 2019, 05:43:05 PM »
It does after the connection begins, yes, but when RM transmits an ACK response back to you - the very next line of my code resets its internal Epoch to -1, so that the next datagram it processes (assumedly a temp datagram) will always have a larger Epoch.

What is the interval between packet sends in your code? I’d ry the following:

1) Try setting the send interval to every 2 or 3 seconds to make sure that datagrams are not "bottlenecking” on the network interface of either devices and being a) discarded or b) processed out of order.

2) Try sending the following string constant instead of the actual information that you build: {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}

This is the same string that you originally posted, minus the Epoch. I tried this on my end, and got a connection instantly. When sending datagrams, if you do NOT include an Epoch, RM will process every datagram it receives without question. That may shed some light as to whether or not the Epoch is mucking things up

3) Finally, make sure that the methods you are using to LOG the information you posted (IP addresses, JSON strings, etc.) are actually logging the same information you’re sending. Sounds silly, but I’ve encountered many situations while coding where I formulate data for use, encounter a problem, and then re-formulate that data for logging and can’t find the problem. Often, it’s because the logging method is building it differently (not escaping quote marks, missing a comma, referencing the wrong variable etc.). If your logging method isn't already doing so, try logging the data exactly as it is being send.

Let me know - I'm very interested to know what the issue is.

Support / Re: RDP DIY
« on: June 13, 2019, 03:24:31 PM »
Hi alja

It has WiFi, so looks like it would work fine.

The Arduino IDE uses libraries (often written by Adafruit) to access these breakout boards they sell. It would probably be a different library than the one in the sample code (for the Feather HUZZAH), so you would have to import the appropriate library, and then tweak the sample code based on the functions it supplies and its operation. The same applies to the Max chip if it varies from the sample code. But - for functionality - it looks just as good as the HUZZAH.

Make sure you get a power supply, breadboard, and wires.

Support / Re: RDP probe unlinked/offline
« on: June 13, 2019, 01:25:16 PM »
Everything looks right to me.

I fired up my own RDP sender test app, and replaced the JSON I was generating based on UISliders and such, by pasting one of your Temp datagram JSON strings - just subbing out the Epoch for another value to make it easy. {"RPVersion":"RDP_1.0","RPSerial":"Probe1","RPEpoch":1560432161,"RPPayload":[{"RPEventType":3,"RPChannel":1,"RPValue":99.90,"RPMetaType":3001}]}

RM connects as expected.

Do you have the "Channel" field set to 1 in the Probe definition in RM? That's the only thing I can think of that would prevent a connection.

See screenshot for the results I get. It will look a little different than yours - the next version of RM has a lot of new features for probes and curves, but the 3 things that RDP requires: - UDP Port, Serial and Channel - are still the same.

Support / Re: RDP probe unlinked/offline
« on: June 12, 2019, 11:54:57 PM »
Hi Kasper

So, you've got it to the point where you send a SYN request, and Roastmaster replies back with an ACK, correct?

If so, then it's probably a simple formatting issue.

Can you reply back with a sample of the JSON that you create as text for a temp reading? I'll see if I can spot the problem.


Support / Re: ThermaQ WiFi Compatible?
« on: June 06, 2019, 11:13:01 PM »
Just the ThermaQ Blue, at the moment.

Quality wise, they should be exactly the same. Roastmaster will show you all the temperatures concurrently (based on the defined curves in a roast), so the extra screen real estate of the WiFi model doesn't yield any real benefit in practice. But that model does add complexity by necessitating a wireless network. The ThermaQ Blue model, of course, is a direct Bluetooth connection - it's easier and doesn't involve any other electronics, so I haven't given much thought to adding support for the WiFi model.

Pages: [1] 2 3 ... 25