I want to show a study, if we can use make a design for Luke’s USB control solution & the OCC design for a common NDS body housing. I had the possibility to go on a more ore less "professional" PCB production.

Markus,Good job on the board, looks good. This can be simplified quite a bit though, the ATmeaga, FT232, and USB switch are not needed. Also if using an ATmega for switching of the remote release, an external oscillator is not needed, the internal 8mhz oscillator can be used (would have to write the code in none arduino setup).

In my design the CPLD or vinculum can control the camera remote release cable so the ATmega is not needed. BGA parts generally push the board to 4 layers and beyond which adds a lot of cost thus should be avoided if a 2 layer board can be used. Assembly and rework can also only be done with specialty equipment like a hot plate, hot air workstation, and a lot of practice, not DIY friendly. On this design a 2 layer board with a TQFP CPLD would be a better choice.

Steve & Martin,The cases could be made on a 3D printer for relatively low cost

@LukeAbout the ATmega: Are you sure to remove? With the Mega we can use sensors and more for other controlling stuff.Only with USB Control you are right.

I am not using a uC in my design and it is not needed but you can put one in if you like. If you want the DS to be able to communicate with the uC an interface would have to implemented in the CPLD or a bidirectional latch would have to be used.

Edit: To clarify, if you would like to communicate with the FTDI vinculum and a uC a larger pin count CPLD would have to be used to, like the 64-pin version.

If we discuss if usinq a uC or not or a two or four layer pcb i would suggest to invide everyone who develops the occ to make a list what the occ shold be able to support.

This means what is needed, what is realizable and things that are nice to have.

Based on this parameters it´s much more easy to develop a really brilliant OCC.

I hope everyone agrees with this.

So let´s start a "brainstorm" and then let us talk about the best way to realize this brilliant occ project.

My conception of the occ should support:

-> normal operation over the shutter releas cable / connector 3pin 2,5mm ( to use modular cables depending on the used camera )-> alternate control for the camera using usb port (micro usb plug)-> easy way to update if using a uC is installed-> sound trigger input, output to trigger a panorama head, optical trigger by light (photosensor) / combined connector 4pin 2,5mm (adaptercable can be used)-> using a standard GBA Case (cheap, everywhere ww to get)-> optical control of funtion by LED-> dyi friendly to build

DIY friendly & Open Source. is the main reason why we have got this far. so diy is a main criteria.

control of the camera through usb should be another criteria because some "newer" cameras don't support under 1 second exposures using the shutter release. and its more accurate using the cameras timing facility. it should use the shutter release cable for the longer exposures that extend beyond the cameras capabilities aka <30 seconds

sound trigger input is already on the GBA itself. adding another 2.5mm plug for a microphone could be counter productive and could take up alot of pcb space.

putting a small photo sensor like a 2 prong thing like this http://www.weinproducts.com/s14.jpg coukld work but if its on the ds cartridge you might have to use very reflective clothing aka white to set it off because it will be facing towards the ds user... thats what you mean right?

"input, output to trigger a panorama head," im trying to seek more details on that panorama head created with the mini arduino posted in the "general chat forum" im sure they will be able to communicate with eachother somewhat it will just take some fiddling and playing.

sound trigger input is already on the GBA itself. adding another 2.5mm plug for a microphone could be counter productive and could take up alot of pcb space.

-> you are right, i forgot it... my fault ;o)

Quote:

putting a small photo sensor like a 2 prong thing like this http://www.weinproducts.com/s14.jpg coukld work but if its on the ds cartridge you might have to use very reflective clothing aka white to set it off because it will be facing towards the ds user... thats what you mean right?

-> yes, that´s what i mean. Maybe by using it with a external cable it is more easy to handle it.

sound would probably get the firework first time. although light would be more efficient with a delay.

light sensor with a delay should work fine for FIREWORKS. but for a fireworks program you need to change the sensitivity of the sensor and add a delay from when the ds recieves a light reading to when it shoots. (.1second increments?)this is because people might want different effects.

other than fireworks i dont think photographers will need a light sensor unless its going to be a ambient light meter like the sekonic 308s telling users a shutter speed recommendation based on ISO and aperture. (would save photographers about £100 or $150USD) because i never 100% trust a camera meter. although i trust the histogram of a taken photo

the if there is a photosensor on the ds it might not be able to see FIREWORKS because its on the cartridge and facing the wrong way. or even on a WIRE you will have to hold it or place it somewhere. probably hot shoe?. facing 45 degrees up could be best, (attachment for ds controller)

this is where my theory of WIRELESS comes in. if anything thats just a

fantasy

of mine..

put the ATmega and the blue tooth into the CARTRIDGE and put the vincl chip on the hotshoe of the camera (no power exchange just a hot shoe sized piece of plastic) with a short USB wire and SHORT shutter cable release it might save time squeezing things into the DS cartridge. but that means getting power from another source. and sorting how bluetooth talks back and forth.

FACT:back in the day of the IRA (Ireland "terrorists") they used to use flashes and slaves units to trigger bombs....

FTDI Vinculum I option, current prototype:The PTP\MTP USB code is executed on the DS, AVR, or any other device controller the FTDI vinculum I. The vinculum just acts as the dummy USB host. The PTP/MTP code is cross platform compatible which allows for easier development on an atmel AVR and you do not need the DS to control a camera if you want to implement an AVR controller. This design is a stand along controller; it only controls a camera via USB and/or shutter release cable and does not have any expansion abilities for other sensors. If using a DS to control this more I/O could be added but a larger CPLD and possibly a uC would be needed.

FTDI Vinculum II option, all-in-one solution:The FTDI Vinculum II is a programmable 16-bit uC with a built in dual USB host controllers and a great deal of pre-written libraries. The chip is due out in the next few months we need to play around with it and see if it fits all the needs, it could be a huge pain write code and interface with USB devices like camera, we will see. If it is easy to devolve on then a single controller board with expansion connectors could be made; you could connect any accessories or sensors you wanted and add the appropriate code for it the FTDI uC. This would be much simpler and lower cost than trying to make a board with everything on it. It would also allow for anyone to add whatever I/O they want on their own without having to do a full board redesign. Also you could control it with multiple interfaces; you can connect to it with PFIFO to connect to the DS via the GBA slot and with a CPLD interface, you could connect to it via Bluetooth with a serial Bluetooth module. You could also connect to it via SPI and UART for other projects.

FTDI Vinculum II option, stand alone camera controller board (remote release cable and USB controller):An improving on the first option and very similar to the above option. The FTDI vinculum II would not be the central control for everything. It would just be a module/board that you could connect to any project board, including the DS, to control a camera via USB and/or shutter remote release cable. It would have PFIFO, UART, or SPI interfaces as the above option but another microcontroller would need to tell it to take shot, change camera setting, etc. In the case of the OCC, the DS would be telling it what to do. I feel this would be the best solution as it would allow anyone to implement any extra I/O, sensors, and controls they want on their own development platform, process the data from that I/O how they want tell the camera controller board to do whatever they like without having to implement the USB PTP/MTP specification in their code.

I feel a standard USB-A connector should be used on the USB controller instead of a micro USB connector. That way anyone can use an off-the-shelf USB A to USB mini B cable or buy one at any store if they lose or break it.

I feel a standard USB-A connector should be used on the USB controller instead of a micro USB connector.That way anyone can use an off-the-shelf USB A to USB mini B cable or buy one at any store if they lose or break it.

There are two problem with the mini usb plug. First: the mini usb plug doesn´t lock the connection ( the micro usb port has this feature ) and second: the connector is to high and doesn´t allow the installation in the standard GBA Case. ( allready tested, you are not able to close the cover. It´s 1mm to high )

Achim,The mini plug is on the camera side, I was saying a standard large USB A plug should be used on the USB controller board. It will have to extent out of the GBA case if everything is put into a standard GBA case but it would fit into a big wario GBA case or custom case. A standard USB A connector does have retaining clips that grab the USB A male plug.

Another option to allow a small GBA case to be used is to separate the USB / shutter release controller board from the slot-2 GBA DMA conversion interface (CPLD). A small cable could connect the two boards, this would make sense if the last option I described in my above post were used.

Edit: Sorry if my post came off the wrong way. Have you been able to locate a USB micro-B male (usb host controller) to USB mini-B male (camera) cable or an adapter from USB micro-B male to standard USB A female to allow a standard cable to be used?