Hempstead

Sure... as soon as the account request is approved.

User Manual Correction v.1.0.1 I apologize to those who read the User Manual and clicked on the links to libHemp.zip and Hempstick.zip in the PDF file... they don't exist anymore. I have corrected the document on pp.12 to reflect the the move of the source code to GitHub. For the full announcement, please see http://www.hempstick.org/jforum/posts/list/0/6.page#6 Also apologies to those who tried to download the user manual and got 404 yesterday... I honestly forgot I had to put those documents back after I updated the site pages. Sorry, I got to get this process better and less error prone.

You can now PM me at http://www.hempstick.org/jforum to order the PTFE ring. Does not matter which way you do it, PM here or there, I get an email notification and my computer dings me about it.

Hempstick Forum is Online I have added a JForum on http://www.hempstick.org. You can either use the link on the site or you can directly hit it with your browser at http://www.hempstick.org/jforum. Fire up your questions, suggestions, and requests (or demands;-). The Hempstick site now has minimal information. Everything is work in progress, more information will be added slowly, as well as features. Check back often. From here on forward, announcements will be posted on the Hempstick forum. But milestone and important announcements will be cross posted here for your convenience. And you can also PM me there for ordering the PTFE ring.

For toggles, buttons, switches, and anything electronics, Mouser and Digikey have quite some comprehensive collections. But they are a bit more expensive than others. The other one is Grainger. But Grainger is more of anything hardware as opposed to Mouser & Digikey's electronics focus. The other two are Sparkfun & AdaFruit. These are more geared toward the "Maker" crowd. For controller... Obviously I am biased toward Hempstick.

Yes, very easy. Just change a couple of lines in the header file and configuration files and change the USB descriptor to match and you are done. No code change. However, the current supported boards do not wire all the leads out, and they have some on board "stuff" like additional RAM, SD card, etc. that are wired up already. But you can make a vanilla board to bring out all of them.

I can't really say how complicated it would be to really drive the FF motors. So far, Hempstick does only input to the host, but not output. If they really use the standard USB HID FF standard, it shouldn't be too difficult to change the device descriptor and report descriptor and to invoke an RTOS task when a report is received. But what the task does, I have no idea. Particularly, I have no idea how G940 and FFB2's motor drive work. You got to reverse engineer that first. If they use custom Windows driver and sends custom protocol over to the controller, then you got to reverse engineer that protocol too. It's OpenSource, take a crack at it.... I can help, but output to it is low on my priority. I will soon put up a forum on http://www.hempstick.org to support the Hempstick though.

Did you run 22 wires into the Cougar stick with the Bodnar board or 5? With Hempstick, I run 5 using the original PS2 connector; didn't even open the stick to rewire anything. True for regular pit builders that Hempstick just turns your whatever creation into a regular USB HID controller; that's the whole point so it requires no special driver on the OS side! ;-) But it's possible to use TARGET to do the curve and more. Bodnar can't do that. He does that, he will probably lose his USB license over that. But he might be able to implement similar feature and let you change it. I don't know, I am not a lawyer. However, I don't have a USB license to lose and I am not doing it. You are doing it. And it's NOT ILLEGAL for you to do it. USB developers do it all the time. It just might be illegal for me to tell you how to do it, because of DMCA. So I am not tell you how, just that it can be done easily with Hempstick. And it uses much more powerful 32bit ARMs MCUs than other flight sim controllers out there. You can do a hell lot more with these ARMs. Reading the ThrustMaster Cougar/Warthog sticks is just one such example. You want more sensors, and outputs, write it up. There's plenty of CPU cycles available! Actually, this is one of the main initial points I had against using the Bodnar board myself. I bought a Bodnar board, and found out I can't do a lot of things I want it to do. So, I decided to roll my own, which eventually evolved into Hempstick. Since it's OpenSourced, it's perfectly ok for somebody else to design a board laid out more friendly to pit builders, burn custom Hempstick firmware on them, and sell them. It's just that I ain't gonna do that.

That should work, although I have not done it myself. If you wish to have Hempstick masquerading as a TM Cougar, I cannot tell you exactly how, in fear of DMCA. But it should be just some configuration changes without any source code modification. Take a look at this post on SimHQ 3+ years ago, http://simhq.com/forum/ubbthreads.php/topics/3140402#Post3140402. That CADDY was my old handle on CougarWorld. However, Cougar has some of the configuration/settings sent to the board and stored right there, including axe curves. Hempstick does not do that. So, even if you make it masquerade as a Cougar, you cannot use Foxy to configure it. It's just not a Cougar and I have no intention of making it a Cougar. Why bother? Use vJoy.

Yes, it's released under GPL v.2. Free as in freedom!

http://Http://www.hempstick.org Announcing Hempstick OpenSource USB firmware for Joystick and general purpose flight sim controller. 1. Uses Atmel's ARM 32bit MCUs, up to 120Mhz. 2. You buy the supported boards from either Atmel directly or buy the Arduino Due board from anywhere (none of my business). 3. Contains FreeRTOS, a real-time operating system and is fully multi-threaded, unlike Arduino's dumb busy polling loop wasting CPU cycles. 4. Uses voltage level change event-based interrupt handlers tasks to read buttons and switches. No button press, no CPU cycles used. 5. Up to 16 channels of 12bit ADC. Contain a digital averaging noise filter. Can use over-sampling to increase resolution to 14bit w/ software (can do 16bit, but I personally feel it's quite phony so it's artificially limited to 14bit). ADC reading uses DMA freewheeling, without software intervention, so you always get the latest ADC values at the USB report time. 7. Reads TM Cougar and Warthog sticks with hardware (only for MCUs that have SSC modules, SAM4S and SAM3X), so it doesn't waste CPU cycles to generate the right wave form for the stick's buffer. 8. 1000 samples per second, max a full speed USB can do. There is plenty of CPU to do more, but no point of doing that. 9. Configure the USB VID/PID to anything you want. My CH rudder is, for instance, configured as TM16000, as I don't have any USB VID. Works just fine. Currently, these values are compiled in. A planed feature would let you configure them at runtime, as these are written in SRAM, unlike some written in ROM. 10. You get the source code, install the IDE, change a configuration file, press a button and it burns the firmware for you. Instructions in the form of PDF and iBook. For some boards, you will need to buy a hardware programmer, but for some other boards, Atmel includes an EDBG chip on board that allows you to debug/program the MCU w/o additional hardware debugger. Yes, you read that right, YOU BURN THE FIRMWARE. Don't worry, I have step-by-step screen shot instructions walking you through downloading/installing the software tools to pressing the button to compile/burn the firmware. Installing the IDE is not unlike installing a game program. After the installation, all you will need to do are unzip the source code, open the two projects, change a config file and press the build button. 11. Uses Atmel Software Foundation library, so supporting newer faster/better Atmel MCUs would be quite simple. For instance, I just got my paws on a SAM4E board that has a build in Ethernet on die, and Atmel's W23 WiFi module is just announced and availability is imminent. Planed feature includes reading MLX90363 ion SPI digital mode.

If you really want flexibility.... you might wanna wait for my Hempstick controller firmware. Yes. I wrote the firmware last year. I don't design the electronics. I just use ready made boards that uses Atmel's ARM processors, like Arduino Due, and Atmel's SAM4S XPlained Pro. These are 32bit MCUs, up to 120MHz, I have been using the predecessor version of this firmware for my CH rudder to work in TARGET for 2 or 3 years. It contains a FreeRTOS, and is full Multi-Threaded, using interrupt based button/switch reading (unlike Arduino's dumb polling loop for reading sensors/buttons/switches wasting CPU cycles). It can do 1000 sample rate (max. USB Full Speed can do; some Atmel MCUs can do high speed USB, enabling even higher sample rate, but I doubt the utility of over 1000 reports per second). This leaves the MCU cycles free to do a hell lot more things, like reading TM Cougar/Warthog sticks (although I actually use an on die hardware module to read the stick without CPU cycles. ;-). If I have time, and am able to crack the damned protocol, maybe I will support controlling NeoPixels. The source code is up on GitHub, but the main web site is still not up yet. If you are interested, keep an eye on http://www.hempstick.org. It will be up soon, as soon as I can make a bracket to mount the new rack mount server under one of my tables. ;-)

There are two kinds. One is analog, one is digital. The analog one is not called NeoPixel, and cannot be individually addressed, i.e. you control the whole strip with the same color and power, but cannot say pixel one with R50%/G50%/B50%, pixel #2 R10%/G20%/B30%, ... etc. However, the analog ones should work fine for panel backlighting. AdaFruit even sells a ready-made controller for analog strips with which you can adjust the color and intensity. AdaFruit also has a controller called PhaseCandy for controlling strips of NeoPixels. But as far as I understand, you need some software/computer to "program" it.

This has been there for quite some time on AdaFruit, since last year. It has quite some weird protocol. AdaFruit has an Arduino hand tweaked assembly to get it to work. They can be cut down to individual units, each consists of one NeoPixel, plus one current limiting resistor, a complete unit. You can NOT drive it with a straight DC or PWM. You must drive it with a serial protocol. The protocol is basically an 800 baud asynchronous serial protocol, no start, no parity, no stop bit, 8 bit data. No Hardware UART can do no stop bit (either it's 1, 1.5 or 2 stop bits, or longer, but never 0), b/c basically asynchronous serial protocol requires start and stop bit to mark each char. Synchronous serial protocol requires no stop bit, but needs a clock line. But NeoPixel does not have a clock line, so it's sort of a hybrid of an async and sync protocol. And it's sort of a modified NRZ. 1.25ms per bit, 0.4 mark is 1, 0.8 mark is 0. I have been thinking about how to make hardware USART built in to Atmel SAM MCU to drive it instead of using AdaFruit's time sensitive not-exactly-portable software assembly code to drive it (I write my own firmware to drive my panels and joystick/rudder, soon to be OpenSourced). But I have not gotten it to work yet. And for me, driving NeoPixel obviously has lower priority than other features like reading MLX90363 hall sensor, or reading TM's Warthog/Cougar stick. Please do let me know, if you have any luck with it. I'd be very interested.

Really? That'd be interesting to see. Would you mind posting a picture of it? Let's just make sure it's not the Chinese workers omitted the rubber ring, which would cause wear of the ABS plastic rubbing against the steel plate. If true that TM has changed the design without the rubber ring, I'd be glad to get out of this making PTFE ring thing eventually. ;-)

The funny thing is that you went to Russia to hunt for the man who is about 15 miles away from you. Such is the Internet. :smilewink:

http://www.adafruit.com/products/1303

Haha, I didn't say it's gonna be cheap. ;-) Now you know the part #, just keep checking eBay... I got a batch of 5 brand new ones rebranded as Lockheed Martin... for $5 each. I did make a rubber mold of the knobs and successfully cast a couple of them out of clear epoxy. However, I still can't find the D shaped tube inside the knob to accept the shaft of POTS. And making it myself is just way too much trouble.. I am sure somebody makes those and sells them to knob manufacturers. If anybody knows where to buy such tubes, please let me know!

http://www.peerlesselectronics.com/store/products/MS91528%252d001B.html

http://www.peerlesselectronics.com/store/products/MS25165%252d3.html

In case you are interested.... The middle two knobs of your lighting control panel are of the wrong type. See the attached picture of a genuine A10 simulator lighting control panel. I took the top middle knob off to show what how the backlight is transmitted into the knobs - by unpainted frosted circles under the knobs.

For ordering stock PTFE rings, just PM me and I will send you the info. for ordering. As to making thicker PTFE ring twice as thick as the original Warthog ring... the original Warthog O-ring is about 1.56mm thick. The stock PTFE ring is 3.175mm (1/8" thick), slightly more than 2x as thick already. Or do you mean that you want one that is 1/4" thick? I am not entirely sure if that will fit inside the Warthog without interfering with the upward movement of the spring piston platform. If your purpose is to have more spring force... I'd suggest making some steel rings and put them at the end of the main spring. Don't put it at the platform end. The platform has a groove to center the spring so the spring does not chafe against the platform wall. If machining a steel ring is a problem for you.... A hackish way of doing it is to take a steel wire (or bronze/brass wire you commonly find in HomeDepot for tying brushes in your garden), bend it into a ring of exactly the same diameter of the main spring, hammer it slightly flat, then use some tie wire to attach it to the end of the main spring. But I will not suggest welding/brazing the new ring to the main spring... it's kind of irreversible with welding/brazing, and the welding/brazing heat might affect the tamper of the spring...

I don't think what the video demonstrated is the same thing as auto-zero in Mach 3. What the auto-leveller does is that it samples the z-height at multiple points on the board. Then PCB-GCode generates gcode with compensated z-height to account for the "unlevelness" of the board. A couple lines of code, and some ingenuity and you don't need a complicated z-height compensation mechanism anymore. Absolutely brilliant!

Here's a SOIC 8 complete circuit with an MLX90333 in an analog output configuration I did 5 or 6 years ago for the DiHXY hall sensor for Cougar, years before the Warthog. The WxH of the PCB is 0.65"x0.65". The SMD resistors and capacitors are 0805's. Since it's a SOIC 8, the pitch is about 0.05", i.e. 50 mil and the width of the legs are about 15 mil. I used a 5 mil end mill. Due to runout of the spindle, the path it cuts is perhaps about 6 mil. The small traces to the capacitors are about 10 mil. except the power trace (20 mil) and you can see that not all the traces come out exactly 10 mil. The input/output legs are soldered in for IDC 0.1" pitch connectors. I would say anything smaller would be pushing it with this setup. It's doable, but I must tell you that I had to tweak the backlash nuts of my tiny desktop mill so much that I actually ruined the backlash nuts. It's not very health for this mill to run such tight backlash! It actually would bind at the end of the ACME screw run. You probably would need some precision double nut ball screws to run anything smaller. But the good news is that very few sensors are smaller than SOICs (Unfortunately newer MCUs are often smaller LQPF 0.5 or even BGAs). This is my prototype circuit so I left it bare without any coating and it oxidizes quite a bit.

The right side is the real one from the real A-10 Simulator (won the bid on eBay, it's the whole self-contained lighting control unit including all the electronics and they use AC Variable Voltage Transformers instead of POTS!!! OMG, how much is one of those things costs when new???!!!!). The left side is my reproduction. Laser engraved on the front, pocketed, outlined cut on an CNC'd RF-45. The large recess pocket on the back is for PCB for LED lighting (the original uses a phenolic board with aluminum foil as tracks and incandescent bulb for backlighting). The large recess was milled with a 3/4" and a 1/4" Osrund Carbide upcut endmil. Then, the whole thing is glass bead blasted. Still needs to white fill the lettering, then paint the whole thing black... and finish my USB controller firmware. I write my own USB firmware for it using Atmel's evaluation board (and a Arduino Due, all 32bit ARM chips). It contains a FreeRTOS real time OS in it. And the whole thing runs multithreaded. It even has a running average digital filter to smooth out the noises. And it also has a over-sampling to "artificially" increases resolution to 16 bit ADC (to be honest with you, I think the oversampling is gimmicky). It is also capable of reading the Warhog/Cougar sticks (but only on selected models of Atmel chips that contains SSC modules, like SAM4S or SAM3X on Due). I am looking into support SAM4E chips, which has a real 16bit ADC on it, as soon as I get my hands on one of the boards. The predecessor of this firmware powers my CH rudder, of which TARGET accepts it and I program it using TARGET and combined it with my Warthog. It's been doing that flawlessly for the last 3+ years. I will OpenSource it soon (the Rack Mount server for it is already on my desk).