rAtTrax with MUI, SpinOFF All-in-one

[designer2k2]

played a bit more with Fritzing now, this is actually quite nice! Just a jump from all the options to a basic tool set, but slowly getting it

The Gerber export is fine (now that i see it), but some board houses require specific filenames for the layers (for example http://www.leiton.de/ or http://dirtypcbs.com/) and Target does this for me, with Fritzing i need to rename them, but thats actually something what can be done with an batchfile.

There are so many ARM boards around: http://en.wikipedia.org/wiki/Comparison ... .2C_memory
For example the Banana Pi http://www.bananapi.org/p/product.html http://de.wikipedia.org/wiki/Banana_Pi, a dualcore 1ghz 1gb ram for about 40€.
But its tricky to choose one, as not all have open tool chains, or are far away from automotive grade, or have no direct I/O access, making I2C and SPI difficult to realize.

That 90´s board is awesome! Feels like school again for me, learned it the same way

[landracer]

Great day to you, good sir!

Yes ARM board saturation, oh goodness..... Hell its in your pocket right now and you probably took a few calls on it today as well I suggest looking @Cibieboard stuff. That all seems pretty opensource all the way down to board design. I have a hard time advocating for any of them though. I own a few different models from different makers. cubieboard 1&2, cubietruck, beaglebone black,and a few odroids XU's in the wild around here. YET playing with all of those they seem to come to an end of life rather abruptly. If no one is compiling hardware specific images for these machines/hardware they seem to die off for their next model version. I'd rather make my own that we can integrate into the project. That way the products end of life can be controlled in-house. Just a little thought anyhow, sounds fun I love embedded hardware it's just some sweet stuff.

Sometimes basic and simple is best. Being able to quickly prototyping is not really a bad thing... Yes lacking all those bells and whistles. But myself, in a software sense, I don't really want to deal with much other then, design, build, produce. As much as I love building things and tinkering around. Yes lacking, the program is still being heavily developed. I am sure we are yet to see some of the best features. They have not yet arrived. So not that any of the time spent playing with Fritz is in vein or a waste. I do feel like it needs a more sprucing.
Careful on undoing to many things at once, it seems to forget where its at. I've seen it leave stray components from an undo and I click on it an BOOM crash. I think I got it to do that 3 separate times. So there are quirks. Also I noticed, for example. SMD 1206 Resistors/caps(other size stuff too). There are a bunch of flavors of the same with different component look same board layout. But one of them allows for a bunch of changes without modifying the part, inside the right lower dialog info box.(easier then say, edit part, and save as you need. I was doing that) So using the "same' different component has a world of other options. IT also looks way better in your schematic. I have to replace a bunch of shit to make mine look right to me. Hence where I screwed up and didn't notice till I was about 75% done laying out that first board. oops.. my bad.

[designer2k2]

just tried to figure how to use SPI and I2C on the cubieboard/raspbi/banana. and oh my, this is not straight forward.
i think the arm discussion should be done separately in another thread.

Yeah, the "undo" button is not realy working, its messing up quite a bit...
Looking up the Bugtracker with "undo" is opening a world of problems

[landracer]

Yeah it can be pretty bad.. I just worked around the issue myself. Not to say the program didn't close out on me a few times this round as well. Damn kids toys these days Still a bit more to do, as you can see... But coming along slowly. What was the intentions with the LED feature d4,5,6?

[designer2k2]

D1-6 was intended as a debugging feature, but D4-6 is messing up the multiplexer, they draw too much current -> voltage drops -> bad signal.
You should only put D1-3 on it, they serve the purpose for debugging (if they are blinking, it should work )
https://code.google.com/p/multidisplay/wiki/BuildMD02

For the Layout, try putting the RJ45 jacks as close as possible to the edge, when you add the distance the case will take up it gets tricky to then reach for the little handle on the cables to release them.

Also the C10 is very close to the LM2907, making soldering tricky, i would suggest a clearance of 1x the pad size from the C10.

And one more, C1 for the 5V rail is connected over 2 vias and a bit of track lenght to the data RJ45 jack, maybe you can put it closer and with a direct connection.
The Intention for the C1 is to stabilize the 5V "far away" from the MD01 print, and it should do it as close as possible to the entry point on the MD02/03.

[landracer]

I do wish this damn program did have a better set of measurement tools. This is a joke...

So I changed those few little things. But I think I am going to move things around. I don't think this is close to final. Maybe you can give me your thoughts on mounting the CD74HCT4051 & LTC1050 on a separate board with breakout headers for my EGT's? example below

[landracer]

Definitely swapping places LED's/CAP ....

[designer2k2]

Overall downside from this approach is that you need to carry the analog signal over the RJ45 connection into the ADW´s. I only move digital over the RJ45 line as there is no clear definition on how much resistance the connection points have.
Maybe choose a different connection method?

Think this could fetch some noise, but needs to be verified, best in a car with running engine (so that the ignition and injectors produce electrical noise)

You will also need to move the LM35 (T1?) on the breakout board, and as close as possible to the physical connection from the thermocouples to the PCB.
On the MD03 it is located just next to the headers.

Reason for this is the so called ice-point calibration. When the thermocouple wires hit the headers they form another thermocouple, and it is crucial to know exactly the temperature of this point.
Otherwise your reading will be off by exactly the temperature difference between the LM35 and the temperature from the connection point.

The LTC1050 is a delicate Amp, it makes x95 in one stage, and that with just some mV on the inputs (thermocouple voltage), i would put some good caps very close and ensure a solid ground layout is around, to get as little as possible surrounding noise into the signal.

[bofh]

ARM vs AVR8: yes, thats a stuff for another thread.

but let me say a few words to ARM-Boards: these ARM MCUs are a hell faster than the ATMega2560. but are they better suited for our application on the multidisplay pcb?

We want data acquisition at a constant frequency (for example 12Hz) and need also some advanced hardware features like input capture interrupts.
btw: Data acqusition at defined time intervals is a sort of real-time computing (RTC).
Its much easier to implement this on a dedicated mcu where I'm responsible (and in control) of the complete running firmware.

An ARM board (raspi, cubietruck etc) has a lot more computing power but it runs a full bloat operation system and is therefore not as predictable as the ATMega which is 100% under my control.
Imagine what happens under high system load on an operating system: maybe the linux kernel is busy with memory swapping and therefore the multidisplay process wouldnt get processor time even though it its needed at this point because we want to acquire our data at a constant rate.
Yes, there are some possibilities like RT-Linux to handle such realtime tasks. But it would be a hell more complex than running dedicated firmware on a simple MCU which is controlled 100% by our firmware.

In my opinion, the low-level data acquisition should always be done on a dedicated ATMega.

An ARM board could be an extension to the ATMega instead of a replacement.
btw: ARM extension is already in use: the android smartphone. it handles the visualization and data storage (mUI app).

If we're talking about an in-car graphical OLED / TFT display (i.e. dashboard) with expensive animations the mUI app could be moved from the smartphone to an in-car raspberry pi or similiar ARM board.

[landracer]

She is coming close to a completely embedded system. For some reason this atmega8u2 is not playing nice with my setup. More like doesn't work past taking code and pretending like it is going to work. Even registers as the MEGA2560 board. Then nothing. Regretting not using the FTDI chip now. Why? Because I can hookup and external serial to usb and boom works great! Go figure...