MAXADC-RTD
102 views
Skip to first unread message
James Kemp
Apr 9, 2012, 6:50:57 PM4/9/12
to i3detroi...@googlegroups.com
OK, it's cute. And who could complain about something that's free?
BUT
Without any USB documentation about the protocol it's kinda useless. Sorry to be blunt. Without the magic docs it's going to be hard to make use of this thing.
Maybe, by removing the micro on the backside, a direct connection to the SPI bus going to the ADC chip could be made. Lots of docs about the SPI protocol going to the ADC chip. By going direct, could also make use of the digital IO on the ADC chip. I'm thinking of a reflow oven app here. Read the ADC to know the temperature - use the digital IO to control a Crydom solid state relay that turns the oven on and off. Could all be on a little daughter card on an Arduino (a shield in Arduino speak - I think).
Anyway, without some kinda hack this baby is not much use.
Anyone else got ideas for this thing? I hate to give up so easily on free stuff.
BUT
Without any USB documentation about the protocol it's kinda useless. Sorry to be blunt. Without the magic docs it's going to be hard to make use of this thing.
Maybe, by removing the micro on the backside, a direct connection to the SPI bus going to the ADC chip could be made. Lots of docs about the SPI protocol going to the ADC chip. By going direct, could also make use of the digital IO on the ADC chip. I'm thinking of a reflow oven app here. Read the ADC to know the temperature - use the digital IO to control a Crydom solid state relay that turns the oven on and off. Could all be on a little daughter card on an Arduino (a shield in Arduino speak - I think).
Anyway, without some kinda hack this baby is not much use.
Anyone else got ideas for this thing? I hate to give up so easily on free stuff.
Paul Kerchen
Apr 10, 2012, 11:27:12 AM4/10/12
to i3detroi...@googlegroups.com
Do we have access to a USB protocol analyzer? The device itself appears
to present itself as a standard USB device (because it didn't require
any special drivers before being available to their app), so it might
not be too hard to talk to it and RE the protocol. I'll investigate
further and report my findings....
to present itself as a standard USB device (because it didn't require
any special drivers before being available to their app), so it might
not be too hard to talk to it and RE the protocol. I'll investigate
further and report my findings....
Paul
> --
> You received this message because you are subscribed to the Google
> Groups "i3 Detroit Public" group.
> To post to this group, send email to i3detroi...@googlegroups.com.
> To unsubscribe from this group, send email to
> i3detroit-publ...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/i3detroit-public?hl=en.
Nathaniel Bezanson
Apr 10, 2012, 12:22:36 PM4/10/12
to i3 Detroit Public
On Apr 9, 6:50 pm, James Kemp <Jim.K...@ph-elec.com> wrote:
> I'm thinking of a reflow oven app here.
Is the resistance of molten solder well-understood? Even if you're not
> I'm thinking of a reflow oven app here.
worried about the RTD falling right off the board when things heat up,
it seems to me that the reading might do weird things. I'll stick to
thermocouples, thanks. :)
> Anyway, without some kinda hack this baby is not much use.
On Apr 10, 11:27 am, Paul Kerchen <p...@whirlingchair.com> wrote:
> Do we have access to a USB protocol analyzer? The device itself appears
> to present itself as a standard USB device (because it didn't require
Everyone has access to a USB protocol analyzer. This is but one tool
> Do we have access to a USB protocol analyzer? The device itself appears
> to present itself as a standard USB device (because it didn't require
among several:
http://labs.vmware.com/flings/virtualusb
-Nathaniel-
James Kemp
Apr 10, 2012, 1:55:53 PM4/10/12
to i3detroi...@googlegroups.com
The MAXADC-RTD board uses a 16bit ADC to read the analog input. I haven't look at the details yet but I'm guessing it could read a thermocouple just as easy. I do know the thermistor pullup resistor on the board can be removed easily. Plus, the ADC chip has programmable gains so reading the low level thermocouple shouldn't be a problem. Only downside is a lack of cold-junction compensation. However, being off a couple degrees shouldn't be too big a deal for a reflow oven. It's more about controlling the ramp rate than accurate values.
I've never done much reverse engineering / decoding of USB traffic - sounds like a lot of work. Fore sure, if the ADC chip is going to be used to read a thermocouple the USB protocol will need to be well understood.
Maybe TI would cough up the source code to their GUI interface by simply asking them? Can't see how keeping that a secret helps them much if they want us all to use their chip. I'll post the question on their web site and see what happens.
I've never done much reverse engineering / decoding of USB traffic - sounds like a lot of work. Fore sure, if the ADC chip is going to be used to read a thermocouple the USB protocol will need to be well understood.
Maybe TI would cough up the source code to their GUI interface by simply asking them? Can't see how keeping that a secret helps them much if they want us all to use their chip. I'll post the question on their web site and see what happens.
Joseph C. Bender
Apr 10, 2012, 1:59:05 PM4/10/12
to i3detroi...@googlegroups.com
On 4/10/2012 13:55, James Kemp wrote:
>
> Maybe TI would cough up the source code to their GUI interface by simply
> asking them? Can't see how keeping that a secret helps them much if
> they want us all to use their chip. I'll post the question on their web
> site and see what happens.
>
Not sure what TI is going to do, given it's a Maxim chip. :)>
> Maybe TI would cough up the source code to their GUI interface by simply
> asking them? Can't see how keeping that a secret helps them much if
> they want us all to use their chip. I'll post the question on their web
> site and see what happens.
>
--
Joseph C. Bender
jcbender at bendorius dot com
James Kemp
Apr 10, 2012, 2:08:51 PM4/10/12
to i3detroi...@googlegroups.com
Sorry, I've been fighting all day trying to get TI's tool chain running! Bottom line, using VMware on top of Linux is no good. Seems there is some bug in TI's USB firmware that Linux is sensitive to. After 6 hours a wasted time I'm gonna give up and use a WinXP laptop. Breaks my heart.
--
You received this message because you are subscribed to the Google Groups "i3 Detroit Public" group.
To post to this group, send email to i3detroit-public@googlegroups.com.
To unsubscribe from this group, send email to i3detroit-public+unsubscribe@googlegroups.com.
Neil Funk
Apr 11, 2012, 11:00:20 PM4/11/12
to i3detroi...@googlegroups.com
Showed up on my Linux box as a HID device. Haven't tried to talk to it beyond that though.
-Neil
[410114.788282] usb 2-2.4.3: new full-speed USB device number 7 using ehci_hcd
[410114.802261] hub 2-2.4:1.0: port 3 not reset yet, waiting 10ms
[410114.886500] usb 2-2.4.3: skipped 1 descriptor after interface
[410114.889249] usb 2-2.4.3: default language 0x0409
[410114.894872] usb 2-2.4.3: udev 7, busnum 2, minor = 134
[410114.894876] usb 2-2.4.3: New USB device found, idVendor=0b6a, idProduct=2bcd
[410114.894879] usb 2-2.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[410114.894883] usb 2-2.4.3: Product: MAXQ622 HID Demo
[410114.894886] usb 2-2.4.3: Manufacturer: Maxim
[410114.894980] usb 2-2.4.3: usb_probe_device
[410114.894985] usb 2-2.4.3: configuration #1 chosen from 1 choice
[410114.897389] usb 2-2.4.3: adding 2-2.4.3:1.0 (config #1, interface 0)
[410114.897433] usbhid 2-2.4.3:1.0: usb_probe_interface
[410114.897436] usbhid 2-2.4.3:1.0: usb_probe_interface - got id
[410114.907536] generic-usb 0003:0B6A:2BCD.0005: hidraw4: USB HID v1.10 Device [Maxim MAXQ622
HID Demo] on usb-0000:00:13.2-2.4.3/input0
[410114.907565] drivers/usb/core/inode.c: creating file '007'
On Apr 10, 2012 11:27 AM, "Paul Kerchen" <pa...@whirlingchair.com> wrote:
Do we have access to a USB protocol analyzer? The device itself appears to present itself as a standard USB device (because it didn't require any special drivers before being available to their app), so it might not be too hard to talk to it and RE the protocol. I'll investigate further and report my findings....
Paul
On 4/9/2012 6:50 PM, James Kemp wrote:
OK, it's cute. And who could complain about something that's free?
BUT
Without any USB documentation about the protocol it's kinda useless. Sorry to be blunt. Without the magic docs it's going to be hard to make use of this thing.
Maybe, by removing the micro on the backside, a direct connection to the SPI bus going to the ADC chip could be made. Lots of docs about the SPI protocol going to the ADC chip. By going direct, could also make use of the digital IO on the ADC chip. I'm thinking of a reflow oven app here. Read the ADC to know the temperature - use the digital IO to control a Crydom solid state relay that turns the oven on and off. Could all be on a little daughter card on an Arduino (a shield in Arduino speak - I think).
Anyway, without some kinda hack this baby is not much use.
Anyone else got ideas for this thing? I hate to give up so easily on free stuff.
--
You received this message because you are subscribed to the Google Groups "i3 Detroit Public" group.
To post to this group, send email to i3detroit-public@googlegroups.com.
To unsubscribe from this group, send email to i3detroit-public+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/i3detroit-public?hl=en.
--
You received this message because you are subscribed to the Google Groups "i3 Detroit Public" group.
To post to this group, send email to i3detroit-public@googlegroups.com.
To unsubscribe from this group, send email to i3detroit-public+unsubscribe@googlegroups.com.
James Kemp
Apr 11, 2012, 11:44:30 PM4/11/12
to i3detroi...@googlegroups.com
I did post a question to Maxim asking for either more info or the source code to the Windows GUI. I'll let you know if they respond.
I also got something similar on my machine. I could even open the device with a little Python code. But then what? Note, I have no wish (or time) to reverse engineer the protocol. Wouldn't know how to anyway.
Let's hope Maxim opens up.
~ $ sudo lsusb -d 0b6a:2bcd -v
Bus 001 Device 041: ID 0b6a:2bcd Maxim Integrated Products
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0b6a Maxim Integrated Products
idProduct 0x2bcd
bcdDevice 1.00
iManufacturer 1 Maxim
iProduct 2 MAXQ622 HID Demo
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 28
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
I also got something similar on my machine. I could even open the device with a little Python code. But then what? Note, I have no wish (or time) to reverse engineer the protocol. Wouldn't know how to anyway.
Let's hope Maxim opens up.
~ $ sudo lsusb -d 0b6a:2bcd -v
Bus 001 Device 041: ID 0b6a:2bcd Maxim Integrated Products
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0b6a Maxim Integrated Products
idProduct 0x2bcd
bcdDevice 1.00
iManufacturer 1 Maxim
iProduct 2 MAXQ622 HID Demo
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 28
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
Toby
Apr 11, 2012, 2:39:29 PM4/11/12
to i3detroi...@googlegroups.com
Not sure if the uProcessor on board is password locked - I've not played with it yet. if it is, there's hope:
"Master erase does not require a password and defaults to erasing the user application only. Two Family F commands
are added that allow master erase of user loader and system code:
• Master erase system: Complete system erase.
• Master erase user loader: Erases user loader and user application."
Since the user app data is what you'd want to erase, this seems very possible. The board has an unpopulated jtag so it is wide open for experimentation.
User's guide available here: http://www.maxim-ic.com/datasheet/index.mvp/id/6526
"The ROM loader loads program memory and configures
loader-specific configuration features. To increase
the security of the system, the loader denies access to
the system, user loader, or user-application memories
unless an area-specific password is provided"
"Some applications require protection against unauthorized
viewing of program code memory. For these
applications, access to in-system programming, inapplication
programming, or in-circuit debugging functions
is prohibited until a password has been supplied.
The password is defined as the 16 words of physical
program memory at addresses 0010h to 001Fh.
Three password locks protect three different program
memory segments. When the PWL is set to one (poweron
reset default) and the contents of the memory at
addresses 0010h to 001Fh are any value other than FFh
or 00h, the password is required to access the utility
ROM, including in-circuit debug and in-system programming
routines that allow reading or writing of internal
memory."
- Strydre
"Master erase does not require a password and defaults to erasing the user application only. Two Family F commands
are added that allow master erase of user loader and system code:
• Master erase system: Complete system erase.
• Master erase user loader: Erases user loader and user application."
Since the user app data is what you'd want to erase, this seems very possible. The board has an unpopulated jtag so it is wide open for experimentation.
User's guide available here: http://www.maxim-ic.com/datasheet/index.mvp/id/6526
"The ROM loader loads program memory and configures
loader-specific configuration features. To increase
the security of the system, the loader denies access to
the system, user loader, or user-application memories
unless an area-specific password is provided"
"Some applications require protection against unauthorized
viewing of program code memory. For these
applications, access to in-system programming, inapplication
programming, or in-circuit debugging functions
is prohibited until a password has been supplied.
The password is defined as the 16 words of physical
program memory at addresses 0010h to 001Fh.
Three password locks protect three different program
memory segments. When the PWL is set to one (poweron
reset default) and the contents of the memory at
addresses 0010h to 001Fh are any value other than FFh
or 00h, the password is required to access the utility
ROM, including in-circuit debug and in-system programming
routines that allow reading or writing of internal
memory."
- Strydre
To post to this group, send email to i3detroi...@googlegroups.com.
To unsubscribe from this group, send email to i3detroit-publ...@googlegroups.com.
James Kemp
Apr 12, 2012, 7:28:14 PM4/12/12
to i3detroi...@googlegroups.com
Well, I posted the question (asking for docs and/or source code) on their comment page. I also just sent a direct email request to on their support line. Got an official support request number emailed back already.
Getting the Maxim hardware and software tool-chain setup and working is a whole lot of work. Huge, in fact. Unless, that is, you already know how to deal with the Maxim chip and their tool-chain. I have zero experience with Maxim's micros.
As an example, I just spent the last couple of days getting gcc, eclipse, and mspdebug working together on Ubuntu so I could write code for the TI MSP430 microprocessors. Three days of my life spent on tool-chain issues! And even now, there are still issues I'm going to put off because I'm stick of dealing with tweaking stuff - I just want to write code after all!
I'm still hoping Maxim comes through with something. I can't help but think, after sending out hundreds or thousands of free eval boards, that they want people to play with these things. With just a little documentation and a little Python code this eval kit could be really fun to play with. With just Maxim's Windows GUI it's just kinda ho hum - lets move on.
Getting the Maxim hardware and software tool-chain setup and working is a whole lot of work. Huge, in fact. Unless, that is, you already know how to deal with the Maxim chip and their tool-chain. I have zero experience with Maxim's micros.
As an example, I just spent the last couple of days getting gcc, eclipse, and mspdebug working together on Ubuntu so I could write code for the TI MSP430 microprocessors. Three days of my life spent on tool-chain issues! And even now, there are still issues I'm going to put off because I'm stick of dealing with tweaking stuff - I just want to write code after all!
I'm still hoping Maxim comes through with something. I can't help but think, after sending out hundreds or thousands of free eval boards, that they want people to play with these things. With just a little documentation and a little Python code this eval kit could be really fun to play with. With just Maxim's Windows GUI it's just kinda ho hum - lets move on.
Toby
Apr 22, 2012, 4:52:12 PM4/22/12
to i3detroi...@googlegroups.com
If you can stomach AssemblyMaxim gives out the MAX-IDE for free. If C
is your thing, you can get a free 30 day version of a $1500 C compiler
for the uP at http://www.rowley.co.uk/maxq20/index.htm
is your thing, you can get a free 30 day version of a $1500 C compiler
for the uP at http://www.rowley.co.uk/maxq20/index.htm
Alternatively, you can get the 4k codesize limited kickstart edition
of a compiler here:
http://supp.iar.com/Download/SW/?item=EWMAXQ-KS4
Unless you are a FOSS purist, generating your own GCC toolchain when
one already exists for Windows seems to be a waste of time for small
projects, unless the toolchain generation IS your project.
- Strydre
eric©
Aug 8, 2012, 10:34:17 PM8/8/12
to i3detroi...@googlegroups.com
Same wall I ran into...I figured that if I have to go through that
many hoops to get any results with a chip, then obviously Maxim just
wanted to send me a nifty shelf display.
Eric
On Tue, Aug 7, 2012 at 5:56 PM, PeterO <pol...@gmail.com> wrote:
> Did you get any traction? I asked for the source code from Maxim and they
> said no, but I can look at a datasheet for the ADC.
> Did you get to reversing the USB protocol? Is it an RS-232 over USB like
> the FTDI chips or is it something custom?
many hoops to get any results with a chip, then obviously Maxim just
wanted to send me a nifty shelf display.
Eric
On Tue, Aug 7, 2012 at 5:56 PM, PeterO <pol...@gmail.com> wrote:
> Did you get any traction? I asked for the source code from Maxim and they
> said no, but I can look at a datasheet for the ADC.
> Did you get to reversing the USB protocol? Is it an RS-232 over USB like
> the FTDI chips or is it something custom?
Paul Kerchen
Aug 9, 2012, 9:50:18 AM8/9/12
to i3detroi...@googlegroups.com
F00F and I (mostly F00F) were able to make some progress on reverse
engineering the USB protocol, but I lost interest in it. As I recall,
it was a pretty small amount of data that went between the computer and
the device (< 60 bytes?) and we figured out which bytes contained the
temperature data coming from the device. The next step I was going to
try was to replay the packets to the device and see that I got the same
results back, but I was stymied trying to get the Microsoft WDK working
under 64-bit Windows 7. I think it should be possible to talk to this
device without much work; I just have other more interesting (to me)
projects to work on.
Paul
engineering the USB protocol, but I lost interest in it. As I recall,
it was a pretty small amount of data that went between the computer and
the device (< 60 bytes?) and we figured out which bytes contained the
temperature data coming from the device. The next step I was going to
try was to replay the packets to the device and see that I got the same
results back, but I was stymied trying to get the Microsoft WDK working
under 64-bit Windows 7. I think it should be possible to talk to this
device without much work; I just have other more interesting (to me)
projects to work on.
Paul
Reply all
Reply to author
Forward
0 new messages