Got a call some minutes back...Guess what's arrived...

The controls are freakin smooth; esp. the throttle. Have been glued to rcdeskpilot and fms, but pretty sure what this is going into.

from where did you brought that? for how much? looks very tempting

Flipkart....3.8 k

Latest Updates:

- The last version of gt-jtx-m32 board was ready and going into etching, and I left it somewhere in between

- This last version used a graphic LCD instead of a character LCD. Not happy with the results on the GLCD. Wanted to have something like an attitude indicator or a top view of the joystick on the GLCD but it seems very limited with so much stuff to show on a little screen, things like trims etc...Also the KS0108 based LCD is pretty big in size, almost the size of a 4 inch LCD TV. 

- Took some serious thought and considered replacing the GLCD with a LCD screen based display (a SBC  like raspberry pi or a TV).

- Reengineered some stuff and redesigned the gt-jtx-m32 board to communicate data over serial protocol to another display device. How does this help? One can use a GLCD to display data (like the FrSky telemetry screen), or use a full blown Laptop to show the same data using a USB to serial bridge dongle, as long as a software viewer is installed.

- Commenced on a viewer software in Linux and OpenGL for reading and parsing the data.

- Opened up the larger joystick for an analysis; Looks promising. Pictures attached.

I don't think I will be able to complete this in time for the sweepstakes; what matters at the moment to me is bringing this thing to life.

More joystick pics

It's got metal weights to keep the josytick upright. I won't be relying on this and have made a custom mount for the josytick. Pictures coming soon...

The first screenshot of the viewer (loooooooooooong way to go). That is a rotating 3d sphere in the attitude indicator; this is an example of a telemetry enabled widget.

raspberry pi is the most probable platform at the moment. FPV guys, how about the live video feed going on in the background

awesome

This update will make most sense to electronics enthusiasts.

1. Have been able to work out communication channels on the Raspi and the ATMega brain over SPI, little work left and data will be frequenting to and fro. Wanted to use the UART bridge earlier but since the Rpi already has onboard UART and an SPI port, communication between the Rpi and the ATmega will be on the SPI (frees up the RPi UART pins) so the Frsky UART can straightaway plugin into the RPi (without a 5.0v-3.3v level converter required).

2. Have been able to establish a comm protocol for SPI for basic functions of the gt-jtx. Attached PDF. All docs available on the google code site. Additionally, made a SPI protocol emulator for testing the viability of the protocol. As of now, all seems in order.

Works slow, but the direction seems right as of now.

Boys (with toys and without), here is the SPI communication working...which means 99% of the "distributed system" concept feasibility worry is over and its time to get hands dirty with hardware now . No voice over since this was a screencap.




On the left is the master code, on the right is the slave code in action.

Each command uses 4 bytes. The first byte has the OpCode, the second has data0, the third has data1 and the final byte is used to get back the result (on spi, send a byte to get a byte). For a simple command such as GCV (See below), data0-D7:D4 contains the number of channel for which data is desired. When the SPI system receives data0, it returns back the OpCode, when it receives data1, it returns back upper byte of result, when it receives result byte, it returns the lower byte. The upper byte is shifted 8 bits and OR'ed with the lower byte to get the 16 bit value of the result. PB5 plot shows the SPI clock and PB4 plot shows the MISO line.

In the attached video, I first send OpCode GCV (GetChannelValue) to get the channel value for channel 6. At the moment, the channel values have been hardcoded in the slave (for testing purposes only). We see the result as 600. Then I send OpCode GETT (GetTrim) for channel 6 and that returns 6000 as expected.

You can checkout the gt-jtx serial protocol for further details. OpCode 0 is NOP and OpCode 255 is SYNC

Next step will be to implement handling of all 17 opcodes identified till now in the slave and integrate this with the gt-jtx-m32 codes so the master keeps querying and getting values which can be displayed on either the larger Rpi based displays or the smaller Atmega based displays

I've a question. How many of you would like to see this fitted inside a standard mode 1/2 radio? Any votes?

@ Girish sir.. though most of it is a bouncer for me.. But yeah as a laymen the idea sounds brilliant:)

Girish me

This weekend one radio and Wingman coming your way, my vote definitely

Welcome Gusty sir, look forward to meetup and shake hands with the wingman.

Custom paint job for a custom radio . Not too great, but the next time you see a yellow radio on the field, it could be this. . Paint job need some buffing and cleaning up

This will be housing the tx prototype of gt-jtx, m32 version. 9 channels, analog pots yet to be fitted, custom display on rpi.

I'm close, all 17 opcodes implemented. Need to recode D/R and Expo logic...its sbiffy

With Flit gun, Electric Gun, or brush?

The first coat was with the electric thw second with finit. Shouldve been the other way round. You can see spots

Gentlemen,
the first prototype order of the PCB has come out well, after the initial mirroring problem. Yes, I might soon be able to give you guys DIY kits that can be retrofitted in a 3d joystick or an old transmitter as long as there is enough space inside for the PCB and wires

Some features:

1. 8 analog/digital channels. Use a SPDT toggle switch to make a channel digital, use a 5k pot to make a channel analog (gimbals will connect to first 4 inputs).
2. 5 Digital only channels, only SPDT switches may be connected
3. Connectivity with Raspberry pi/Atmega based HUD via SPI. SPI port doubles up as programming port.
4. Separate D/R switches for each channel. If you dont want three D/R switches, use 1 as D/R and spare two as extra digital only inputs.
5. Future connectivity option with Windows/Linux based PC via USB bridge (will be included in kit)
6. Physical size of PCB is 2.5" x 3.5". Once I make this thing work properyly and the form factor will be reduced further
7. PPM signal port. 2.4 Ghz Turnigy/FlySky and FrSky supported atm.

Nothing out of the above is sales/marketing pitch. I'm making what I'd want in a radio. Everything is on the public domain, still under development

http://code.google.com/p/gt-jtx - the brains
http://code.google.com/p/artrix - raspberry pi based HUD

Keep watching for updates.

GS

Nice work Girish ...

Girish bro,

Thank you Amit and Dr. Dhiraj. Expecting to finish this up soon.

first prototype board fitted with components and inside a pretty much standard sized heli tx (Amit, you'd know this Tx)

- don't like so many headers, they look clumsy
- need a better placement for the board, for putting in a wide GLCD screen, 192 x 64 (like the Taranis or 14MZ) and the RF circuitry.

Looks awesome! 

The SBC based software interface with a 8-channel tx template loaded...will upload a video soon when the hardware is integrated. Position etc of the widgets can be customized by editing a plain text file. In addition, one can create their own meters/gauges if they're good at graphics.

QuoteCommenced on a viewer software in Linux and OpenGL for reading and parsing the data.

Here's the ground control station wired up...

Next task is to port the OpenGL software code from x86 to ARM for raspberry pi!

more...


- An Ardupilot kit is going in as well
- separate monitor for Head Mount Display
- Added a mobile charger in the box too. My phone is always on its last battery levels on the field