Puma board for FreeEMS

[jharvey]

Jared, can you check my work, I think it's correct if your csv was.

I'll try but my time is back to being even more limited that it was this last week. I just shifted jobs. I start my new job Monday. I have some plans for that file that I think will come in handy. Time should iron that thing out.

[TonyS]

Actually, the argument about digiprotect on the rpm in is moot anyway as it needs XOR in there for selection of polarity of signal, and that will make an excellent buffer.

Just curious, but is polarity selection an expected feature / function of this input? Is swapping the two output leads of the VR sensor not an option?

Thanks,
-Huff

[Fred]

Jared, moving it closer to the edge might be hard, that gap is filled with a bunch of narrow traces already, but I'm sure someone will come up with something. Spacers are an option too if worst comes to worst.

As for upstream, upstream = kicad devs/original source/data providers for kicad, etc. i'll leave that up to you as I wouldn't know where to start.

Huff, swapping VR sensor leads can't be done, they have to be polarised correctly always. For an actual VR sensor setup this will always be correct, by default, period. For digital inputs it could change depending on buffers and other shit between cpu and sensor. However, if we standardise on the max setup, with just a pullup on the input, then probably it will work the same always and I can code to whatever the max provides and others can invert their setups if required. The only thing that is certain is that the code will not have configurable polarity for rpm inputs.

Fred.

[Spudmn]

Sorry if this has already been discussed but I am still trying to catch up with every thing. You all work at a fast pace.

I am wanting to add data logging functionality to the board.

If we go for the remote logging device I am going to need the CAN bus or the TTL serial coms signals to be available before they go into 232USB chip.

I would like to request that at least a couple of pads be put on the board before the USB chip so that I can tap off the Tx and Rx at TTL levels to feed the remote logger.

[Spudmn]

Have you considered using the MCP2200 USB->serial converter chip.

It's made by microchip and it works just like the FTDI chip.

Some one found out that it is just a PIC micro.

If you left it standard the PC detects it as a comport. Hack the code on it and it could be a mass storage device.

Just a thought.

Check out the right up.
http://dangerousprototypes.com/2011/01/ ... n-mcp2200/

[jharvey]

Sorry if this has already been discussed but I am still trying to catch up with every thing. You all work at a fast pace.

I understand and I won't prod you like some might. I'm more interested in getting things going then in telling people to do their home work. Of course the more home work you do the better, but there are reasonable boundaries. Welcome along, I look forward to your input. As you do your homework, would you be interested in logging your finding on the wiki? DFH's wiki was a good place to short run the learning curve and filter out the misc chatter of the forums. Puma's wiki is a bit dated if it exists at all. We have been to busy with dev to update that. Can we toss an elbow into you, such that you copy DFH's wiki, then update it with relative info for puma?

I am wanting to add data logging functionality to the board.

If we go for the remote logging device I am going to need the CAN bus or the TTL serial coms signals to be available before they go into 232USB chip.

I forget which pins are CAN. We were able to make a couple accessible, but not very many. There are also several general purpose pins, those might also be CAN capable, I'd have to go dig it up.

Also I've added to the next spin list, that we should add a misc connector under the MCU chip, to allow for expansion on the connector card. Do you have this spin, or are you looking for the next spin? Can you elaborate on your data logging desires? I believe the tunning software can data log via USB, but the USB can't handle the full temp range of the rest of the components. So it's abilities are limited.

[jharvey]

Have you considered using the MCP2200 USB->serial converter chip.

I'm a big fan of the FX2 from Cypress. Very similar to the FTDI, but more flexible. It's basically a small MCU, with USB components. It will do the minimal amount of USB coms automatically, then you upload the firmware to it. This firmware will allow you to program it to what ever you want. For example, if you buy on of the $10 serial to USB connectors, you can send your own firmware during enumeration, and make it an OBDII interface instead of a serial port.

Marcos used the FTDI to minimize the learning curve. It typically works well, he had a reference design, ect. So he went with it. If we look to change the USB chip, I'd like to encourage a look at FX2 easy usb. I believe there are also PSoC's with on board FX2, so you can get some really powerful options for nearly no $. Picture the USB chip also being a scope, would be a nice feature for diag, and such.

[jharvey]

Holly crap Cypress

http://www.cypress.com/?docID=24179

How long until they put the whole world under the hood. It has the FX2 style USB, 32bit ARM Cortex3, 0.5 V to 5.5 and a massive amount of options. Don't know the price or availably. It's not automotive qualified, but does -40 to +85 which is a decent temp range, and would likely be good for com's, and such less critical options.

I haven't looked at PSoC's much lately, but wow, they have moved along.

[Spudmn]

For example, if you buy on of the $10 serial to USB connectors, you can send your own firmware during enumeration, and make it an OBDII interface instead of a serial port.

yeah, that's the sort of thing I thinking. It makes the project more hackable/versatile without compromising the basic functionality for the users that don't want to hack.

As you do your homework, would you be interested in logging your finding on the wiki?

Yuck, Paper work. The first thing I would add to the Wiki is definitions of TLA's. What's DFH's wiki? Where can I find these Wikis?

Do you have this spin, or are you looking for the next spin?

It's looks like I can get Fred's spare PCB. The cost of a lunch might be too high though as it apears that this boy can eat

Can you elaborate on your data logging desires? I believe the tunning software can data log via USB, but the USB can't handle the full temp range of the rest of the components. So it's abilities are limited.

You can follow my thoughts at viewtopic.php?f=8&t=189&start=20

I want to avoid having to carry a Laptop around the race track. If I can tap into the data stream I will log the information to a SD card. I want to avoid going from serial to usb to usb back to serial. At this stage it looks like it might be a small add on board.

[Fred]

I endorse uart <-> uart comms! If you can avoid running over usb/rs232 it's a good thing.

A small board that did just that and logged whatever it sees to an sd card would be mint. Streaming is available, so it can be as dumb as the little one from spark fun recently linked here, or as smart as you like (there will be many different things to request, data wise, if you so want them).

I might include a ride in the first puma powered car with the pcb if you're lucky and I'm lucky ;-)

Fred.