Today we are excited to announce the official release of the G400 Development Board. The G400 Development Board is the official development system from GHI Electronics for the G400D and G400S System on Modules. The G400 offers high performance and extensive capabilities. This development system exposes the various peripherals and interfaces that make it an ideal for any .NET Micro Framework project.
The G400S and G400D SoMs both run the exact same software. The main difference between the two products is that G400D comes in a DIMM package and the G400S comes in a surface mount package. Using the same firmware allows us to focus better on adding features and improving the quality of the software.
The Software Development Kit (SDK) will get you started in no time. All you need is a PC with Visual Studio and the .NET Micro Framework SDK from Microsoft. You simply follow the steps listed here to get started in minutes.The system can be powered through USB or by connecting a power pack (not included).
Is the 4.3" display the same as the T43 Module and is the Touch function available on the development board?
Not obvious from the image, is there a provision for an external antenna for the WIFI module ?
I was waiting since a long time about this board, it meets some 90% of my needs for the product I consider.
I Have to add at least a GPS module for an ultra precise time and 1pps pulse, and temperature, humidity and barometer sensors and some driver boards for servo motors with encoders and stepper motors.
I need 32 to 64 MB of user data RAM, and the G400 is the only one providing such a large memory…
From Gus (GHI) : Why do you need that much memory?! You got me very curious.
We are using devices, improperly named ‘cameras’ because they don’t have optics, with large CCD (more than 2" diagonal), cooled to -30°C to reduce electrons motion, under a Xenon ultra dry atmosphere, with a high QE (up to 70% incident photons are detected) with 4K x 4K matrix and 16 bits per pixel monochrome.
An unbinned image is then 32 MB (4K * 4K *2).
The cameras have some 40 MB (because we need to read also the masked pixels) of internal memory. To reduce the read noise at the level of a few electrons, the reading of the CCD must be perfectly regular, hence is it impossible to perform anything else while reading the CCD matrix.
Once the matrix is read in the camera memory, the CCD matrix is cleared and a new integration may start. Then the camera downloads its memory via USB and here there is no more a need for a steady flow.
Storing 2 images in the G400 allows to perform a double buffering or a preprocessing, depending on the needs, then the image is transmitted via Wi-Fi to the central room, where further more complex processing is performed. Then the images may be dispatched via FTP toward several end users on other continents via Internet or just processed locally.
On a given site, there are several systems, all fully robotized and remotely controlled via Wi-Fi.
Each system has a large autonomy and may have up to 12 motors, although, at least currently, most contain less than that. Currently, each system includes a dedicated PC without keyboard, without mouse and without monitor (the BIOS is set to boot without these devices) running under Windows. The PC performs all the imaging part, receive some scheduling from the central room, send the orders to the cameras and dispatches instructions to a dedicated microprocessor which manages the motors and auxiliary devices. The microprocessor is an 8 bits, 2 or 4 MHz Motorola, and it controls several 20 MHz PIC, each having its own software. As you may see, it is a large distributed system with a lot of layers.
One of us developed, around 1987, a first controller for the motors using an INTEL µP. Other more recent controllers were from of the shelf.
But the electronics is aging, some parts are no more available and we were searching for a quite cheap but powerful system.
The goal is to suppress the PC, and have a unique device, receiving orders from the central room, interpreting these orders, controlling the cameras, but also the motors. The processing is largely decentralized, a single order from the central room (usually a few hundreds of bytes, some kind of script) may provide work for a few dozens of minutes to a remote system.
We developed all the software hence we have a full control, and we are quite sure a G400 will do all the job.
Given your nickname here and the specs you are talking about, it looks like you are driving some kind of astronomical camera. Is it the case ?
Even if not, which CCD are you using and why bin2 (or bin4) are not an option ?
@ Bec a Fuel -
Most CCD are Kodak KAF, from 63xx, 90xx to 163xx.
Binning 4 is never an option, because 4 * 4 = 16 pixels accumulate in the output register, and the output register has never the capacity to accept all the charges, and BTW, in the best case you may run into issues beyond binning 2 * 2.
Second, for large aperture/long focal optics, while binning you may lose too much in resolution. This is all about the application.
