Big project, guidance please..

Hey guys..

I'm working on something.. perhaps a bit advanced for me, but I think I can work through it.

Its a camera controller of sorts. It has :

3 potentiometer joysticks for various camera functions, pan, tilt, zoom, iris, etc.
4x rotary encoders
29 Buttons,
60 odd leds. (most of the buttons are dual colour back-lit)
8x bi-directional RS232C connections (for 8x cameras, individual control)
1x 128x 64 KS108b paralleled LCD with glcd.

My aim is to move all of this to a custom PCB (atmega included) and burn the arduino bootloader onto it.
I'm also leaving room (ie with smart pin selections) for a ethernet port of some form.
I've got a rough schematic running in Altium and a very crude breadboard setup with some buttons and leds etc.

Currently my plan is to use two mega2560s talking to each other on i2c.
ardunio a :
button in
leds out
3x rotary encoder(6 interrupts)

and arduino b:
LCD,
1x rotary encoder
8x softserial ports

I'm at the point of proving i can get the RS232 working. The cameras are all RS232C, 9600baud. 8N1 and do very little talking back to the micro, but i need to be able to read values if I poll the camera ('are you on?', 'yes');

I've done some reading and found softwareSerial is a bit limited in RX.. people suggest ladyada softserials version, or the NewSoftSerial library.. These dont appear to support the mega.

My question :
Am I on the right track with this? or should I be spreading the serials out across the hardware uarts on the two 2560s?
That would mean I'd have to share more of the other bits like button IO as I'd run out of room..
Should I get a third (!) 2560, and have 2560A doing buttons, and share the hardware UARTS of 2560 B and C?
Trying to keep my component list down (ie stay away from shift registers etc) to save on PCB space, which is a bit of a premium in the case I've had designed.

I appreciate your comments..

Cheers

Matt

Whoa that's one heck of a board.

There's so much going on I don't really know where to start, but I'll get the ball rolling.

2 x 2560 is a lot of processing power, almost certainly more than you need but it depends on several factors.
How often to the 60 LEDs have to be updated?
How fast do the encoders turn and do you have to respond in real time?

3 joysticks with pan, tilt, zoom, iris, that's 12 ADC inputs, there goes 1 2560.

3 x 2560 is unheard of, move to an ARM if that's what you really need, for grunt anyway, won't help with IO.

8 x serial, how fast do they have to run? Is that the 9600 to the cameras? It's largely one way which helps. I would think NSS would do this although I haven't used it myself (don't know about the Mega compatibility).

two mega2560s talking to each other on i2c.

I'd use SPI myself, it's faster, but then I haven't used 12c so there may be some bias there.

Rob

Are the RS232 of the camera's 5 Volt or 12 Volt?

If you could multiplex the RS232 you would only need one port and possibly only one 2560. The cameras only respond to a request I understand.

• Do you have a URL of the datasheet of the camera's?

For the LEDS you might consider the Centipede Shield - Centipede Shield V2 - Macetech Electronics Store
It provides you with 64 I/O lines.

Graynomad:
Whoa that's one heck of a board.

There's so much going on I don't really know where to start, but I'll get the ball rolling.

2 x 2560 is a lot of processing power, almost certainly more than you need but it depends on several factors.
How often to the 60 LEDs have to be updated?
How fast do the encoders turn and do you have to respond in real time?

Yeah.. heaps. But I figure for the cost (~$20) Its worth it just to help tidy the code on the first chip.
the Leds are really only updated with button pushes, to make 'toggle' buttons out of momentary ones. There is no requirement for fast updating.
I am slowly trying to talk myself into some form of shift register setup, because Im sure the 2560 wont be able to sink the current of all those leds on at once..
Can you suggest a way of offloading those LEDS to some form of output chip without using a handful of 8ch registers? half as many chips to do 20 each would be nicer.

The encoders adjust colour balance in the picture, and have to respond in real time to help the operator judge his changes. As such they will turn slowly, (less than a revolution/sec ) But would need to be relatively high resolution encoders.

Graynomad:
3 joysticks with pan, tilt, zoom, iris, that's 12 ADC inputs, there goes 1 2560.

I have one joystick for pan and tilt, one for zoom and focus, one for iris and master black (contrast). The tricky bit in the software for these, is turning potientiometric movements inputs into something that can be translated for relational movement.. IE the iris at 0 cant directly relate to camera iris at 0, it needs to take into account you have two cameras selected, both with different current iris levels, and 'drop' the iris on both by the amount you move the joystick. You then get a neutral button to move the joystick to a new position without affecting the levels.
I think I can get my head around how to do this, reading the input, comparing it against a previous read, then subtracting the difference off the variable holding each cameras current level, and sending that out.

Graynomad:
3 x 2560 is unheard of, move to an ARM if that's what you really need, for grunt anyway, won't help with IO.

I would love to get into ARM stuff in the future, however I'm really just getting to grips with the Arduino development environment and code, I'm not sure I'm a strong enough coder to loose that yet. Next project.

Graynomad:
8 x serial, how fast do they have to run? Is that the 9600 to the cameras? It's largely one way which helps. I would think NSS would do this although I haven't used it myself (don't know about the Mega compatibility).

thats the 9600 to the cameras yeah. Largely one way, yes, little bit of talk back, mainly during the setup phase of the day doing things like white balance - that replies with a result.
I've just found a version of NSS which claims mega support, so I'm going to write than in today and see how I go. This is hopefully the answer to my serial issues.
To make things easy for myself, I want to keep the #1 Uart on both chips for the USB-serial - easy debug etc etc.. That brings me to 10 serial ports on my board!

two mega2560s talking to each other on i2c.

I'd use SPI myself, it's faster, but then I haven't used 12c so there may be some bias there.
[/quote]

Cheers Rob. I only said i2c because thats what I've played with. If you say SPI, I'll setup some boards and have a play tomorrow.

KE7GKP:
Note that it is common to make the camera controls modular where one unit (commonly arranged as a vertical strip) controls one camera, and you can place as many camera control strips next to each other as necessary. This reduces the complexity to the controls, indicators, computing and communication necessary for ONE camera. Then you can simply replicate as many as you need. This seems like a much more managable scheme to me. Indeed, it is what I am doing for a similar project.

Here is an example of several identical camera control units in an operational setting...

Hey
I work in a Sports OB truck, we use the newest version of those sony RCPs for our cameras.
The limitation of these is that in a production environment, an operator can really only operate 4 panels - any more and he spends his day rolling up and down the bench on his chair to reach the cameras on the end. I have a requirement for an operator to operate 8.

Not only that but a decent potentiometric joystick costs ~$200!!

The case we have designed matches the sony RCPs in look and feel, only this one is double width.

Can you suggest a way of offloading those LEDS to some form of output chip without using a handful of 8ch registers? half as many chips to do 20 each would be nicer.

I gather you aren't scared of SMD, so have a look at TLC5926 and TLC5927, 16 channels and constant current so you won't need 60 resistors. Then there's the TLC5947 with 24 channels.

Also there are many multiplexing chips, usually designed for 7-seg displays but you can still use discrete LEDs. For example the MAX7219 will drive 64 LEDs.

The SRs will be brighter though as the LEDs aren't MUX'd.

Im sure the 2560 wont be able to sink the current of all those leds on at once..

I haven't looked but I'd say that's right, not to mention that you would need 60 resistors to drive them straight off the processor.

have one joystick for pan and tilt, one for zoom and focus, one for iris and master black (contrast).

OK so that's only 6 ADCs.

You then get a neutral button to move the joystick to a new position without affecting the levels.

Or go the other way, a "do it" button for each camera, or if you need to sometimes do a lot of cameras maybe select toggle buttons. Press X number of toggles then move the joystick. I don't know how practical this would be though in this environment, I haven't been there to know how things work.

What's "normal"? X cameras linked? All three functions linked, ie iris, zoom and pan?

I would think that self-centering joysticks would be best, but for things like iris I reckon knobs and encoders would be better.

Another thing to factor into the iris algorithm is to use ratios not absolute values, ie camera 1 has an iris value if 10 and camera 2 has 100. You wouldn't subtract the same value from each. This assumes the iris setting are linear, they may be log.

That brings me to 10 serial ports on my board!

You have 2 hardware serial ports left, you could MUX them as Robtillaart said, although probably with 50+ IO lines NSS would be cheaper.

Also Rob asked about 5/12v on these serial lines, what voltage levels are they?

I'd use SPI myself, it's faster, but then I haven't used 12c so there may be some bias there.

Moot point if you do it with one processor

Rob

Ah yes, Well.

Short answer is, I dont know.

Long answer is, all the spec can tell me, RS-232C, 9600bps, 8bit 1 stop, no parity or flowcontrol.
Says conforming to RS232C, 3-wire system.
Any idea how I would check? I would have assumed 12v, only because I've seen these cameras used with a few hundred meters of cable, and I'm sure there would have been too much voltage drop at 5v..

I ordered some samples of that TLC5947.. I'll have a play.. (somehow? I dont have a breakout board for it..)
But I'm going to start inserting those into the schematic. 3x of them will be fine, especially with the space i save from lots of resistors!

robtillaart:
Are the RS232 of the camera's 5 Volt or 12 Volt?

If you could multiplex the RS232 you would only need one port and possibly only one 2560. The cameras only respond to a request I understand.

• Do you have a URL of the datasheet of the camera's?

They are a pretty high spec camera, so there isn't a hell of a lot of info available. Heres a URL to get you started..
http://catalog2.panasonic.com/webapp/wcs/stores/servlet/ModelDetail?storeId=11201&catalogId=13051&itemId=97539&catGroupId=14572&surfModel=AK-HC1500G&displayTab=O

Cheers

Matt

Graynomad:

Or go the other way, a "do it" button for each camera, or if you need to sometimes do a lot of cameras maybe select toggle buttons. Press X number of toggles then move the joystick. I don't know how practical this would be though in this environment, I haven't been there to know how things work.

What's "normal"? X cameras linked? All three functions linked, ie iris, zoom and pan?

I would think that self-centering joysticks would be best, but for things like iris I reckon knobs and encoders would be better.

Another thing to factor into the iris algorithm is to use ratios not absolute values, ie camera 1 has an iris value if 10 and camera 2 has 100. You wouldn't subtract the same value from each. This assumes the iris setting are linear, they may be log.

I've got 8 'camera select' buttons, which toggle, and you can select any combination of them at one time. I've also provided a 'select all' and 'clear selection' button.
The reason for the neutral is its an extra output of the iris joystick, push down to get neutral, makes for easy onehanded operation.

Alot of the time they will all be ganged together, to let the operator quickly respond to changes in light level - IE clouds passing overhead.

the pan,tilt and zoom, focus joysticks are self centering. The iris/blacks is actually a lever, up for iris open, down for iris close, with a pot on the handle you can turn to adjust the blacks.
This is a part of another commercial controller i've scavenged. It does not self-center, thus providing the need for the neutral option.

This is a fairly involved project, with many interconnected parts.

Also, it doesn't look like you really are trying to, or need to, do this on the super cheap. Performance trumping cost, as it were.

There are 2 gating items that I can see:

One: While there are 8 serial ports in play, they aren't all that fast. BUT! There are times when all 8 need to work at once without goofy software glitches or delays. This totally rules out SoftwareSerial.

Two: You don't have a year to get this done. So it needs to be simple to program each discreet component without worrying about the need for the same hardware to run other stuff at the same time.

The buttons, LEDs, LCD are easy. No complex timing requirements. The Rotary encoders and joysticks, a little more so, but only on timing issues. The encoders need interrupts (Or dedicated processors) and the joysticks need delays between reads of the A/D ports.

Normally, the rocket science of a project of this scope would be the inter-controller communications. But in this case, they can all be close together, allowing you to use SPI to facilitate this.

So. I would throw processors at it. In the grand scheme of things, Arduinos are a LOT CHEAPER than programmnig and debugging time, and take up very little space.

So: My solution. One Mega as master. It runs the display, the LED's, the buttons, and is the SPI master.

2 more Megas as SPI slaves. These are your 8 serial ports and pick up the slack for whatever buttons and LEDs don't fit well with the master Mega. For example... buttons, LEDs that are camera specific should be on THAT camera's Mega.

4 Pro Minis to run the encoder wheels. All running as SPI slaves. All each one does is run it's own little wheel. Easy to program, no freaky timing interaction bugs with the rest of the stuff.

SPI is easy... and rocket fast. Get that running first. Isolating the cpus makes their jobs a lot easier and more bug free. As a total bonus... you can leverage the product on a 4 cameras at a time basis. A customer wants 16 cameras? Add 2 more Megas.

Phase 3: Profit.

I'm a big fan of multiple CPUs, (recently designed a board with 16 Tiny85s controlled by a mega1284).

It allows each chip to do one or two things well which simplifies much of the code, at the expense of introducing a protocol for them to talk of course. With the above board I planned to daisy-chain all the USI port on the 85s to the SPI on the controller, so the comms would be shiftOut() 16 bytes (commands) and read 16 bytes (results).

I hasten to add I haven't build the board, but I see no real issues with the idea except programming all the chips easily might be a pain.

Rob

Thanks for the replys guys - sorry I'm slow to respond, but I've been busy coding.

I've intergrated 3 TLC5947s into my schematic, which free'd up an awful lot of IO pins,

so now I have one 2560 running 60 Leds, 1x LCD, 29 buttons, 4x encoders, 8x pots, a debug / firmware UART, and UART1 to talk to the other 2560

the other 2560 is running a debug uart, uart1 to talk to the other 2560, and 8x software serial ports via max3232 to talk to cameras.

I've got the Iris, zoom, focus, pan, tilt, power on/ power off, bars, white balance, black balance, etc working

So Over all, pretty stoked. Finding out the hard way how in-accurate this protocol spec is is very frustrating!

Now I'm a bit stumped. I can't get the pedestal value going.

I need to Read an analog input (0,1023) map that to 0-300,
then send that value as two bytes, hex.

Which I assume to be 300 = 0x12C,
Byte 1 = 0x01
Byte 2 = 0x2C

But I'm having a hell of a hard time getting anything to work like that..
Does that sound like the right approach to you? I think its trying to split 0x12C into two bytes thats killing me..

Any hints on this?

Cheers
Matt

In my experience in programming systems spread across many processes, it's the communication protocol that has to come first. Nail that and everything else is just a task.

Ok, so you start with a reference number between 0 and 300, and you need to send it as 2 bytes.

To send binary data across Serial, you can use Serial.write (As opposed to Serial.print)

To separate the bytes, you can use lowByte(int value) and highByte(int value) these each return a byte.

You can then send them to the other Arduino with:
Serial.write(lo_byte);
Serial.write(high_byte);

Then recombine them on the other side with something like:

int int_value = (int)high_byte;
int_value = (int_value << 8) + lo_byte;

Or, you can send both bytes at once with Serial.write:
Serial.write(&int_value,sizeof(int_value));

But be careful if you use the second approach! Some processor types use intel style "Big endian" byte ordering, while others use Motorola style "Little endian" byte ordering. If you transfer 16 or 32 bit values cross platform that uses different ordering, you have to swap all the bytes around.

For example, the AVR processors (Which Arduino runs on) are Little-endian... while Intel CPUs are Big endian. Whenever I send 16 or 32 bytes values from Arduino to Linux, I have to swap the bytes.

This is why you fix the protocol first. Struggling with byte ordering on something that has worked for months but is now totally borked because you're talking to an Intel based machine is not fun.