Hempstead

As promised, the lighting control panel SolidWorks files can be downloaded in the following URL, http://www.hempstick.org/download/warthog/Warthog-LightControlPanel.zip This is measured directly from a real A-10 simulator panel. I bought the whole thing from eBay, which included the "electronics" and the mill-spec connecto and housing. It uses variable power transformer instead of pots (there is one that actually uses a pot) The US military has long standardized on mm as the length unit (standardized is a relative term... a lot of their screws and bolts are still imperial unit ones). But, somehow, the designers are still used to Imperial measurement and they have to work with raw stock that are in imperial units. So, they sometimes have weird mm length that only make sense when you convert them to inches. I have to work with such mixed bag of measurements as well as I live in the US... It's very tough for me to get any raw stock that are in metric (reads expensive). So, I always draw such things in metric units, but uses imperial unit stock. A good example is the thickness of the panel. it's ... 1/4" (the real one is 1/4" thick too!).

With the R1 plan http://hogpits.net/downloads/summary/6-reactorones-a-10-cockpit-panels/19--r1-a-10-panels-.html. It's a good starting point. If you would provide a set of authentic measurements from the "real" thing, that'd be great. Otherwise, I will draw them to the way I like based on the R1 plan. I don't know R1's source data anyway. I displayed R1 plan's lighting panel on my screen, and then put the real panel on it. The location of dials and switches are a bit off, but not too badly off. My lighting panel, however, is from the real thing (even though mine is from a mil simulator, it seems to use the same thing as the real production planes). I do use non-authentic font, but like a former colleague who used to work in the game industry often say -- if it looks good enough, it's good enough. 100% authentic is never my goal.

I have one, the lighting control panel in SolidWorks. It's measured from a real A10 simulator's lighting control unit I bought off eBay. I'd be happy to put it out in the public domain. I will put it up on the Hempstick site this weekend.

Arduino Due/X does have an atmega programmed for Arduino debugging/programming on board. So, if you use it with Arduino IDE, you don't need to buy a separate programmer/debugger. It's just that we can't use this "debugger/programmer" with Atmel Studio, Atmel doesn't support this one. But Arduino folx are graceful enough to wire out the JTAG debugging pins for other debuggers. This is what ATSAM-ICE and Atmel ICE debuggers support. In other words, Arduino Due/X board can be use for both Arduino purpose and anything else, including Atmel Studio for Hempstick, unlike its older brothers. I suspect that there will not be any clone for the XPro boards, because Atmel does not sell the EDBG chip to anybody. Moreover, the cloners have very little incentives to do the XPro's small market. Also, note that Arduino Due/X's JTAG debug header is 10pin 0.5" pitch.... ATSAM-ICE does not come with 0.5" pitch header. You'd have to buy an Olimex adapter and wire for it. Atmel ICE, however is native 10 pin 0.5" pitch. And Due/X's layout has a little problem -- the 10pin 0.5" header won't go in. You'd have to cut a little plastic corner to get it in. No big deal.

AFAIK, F16 FLCS's stick electronics is similar to Cougar and Warthog, just a bit older and slower version. Hempstick should work right out of the box. And you get 14bit instead of Mega's 10 bit. Also, you get 1ms USB report rate, i.e extremely low latency. That is, you turn a game port stick into a state of the art joystick. Just follow the instructions for Cougar and it should work.

It's a simple why question. You read too much into it. Open exchange of ideas is great. That's why I ask why. Because I don't get it. Exchange of idea is not just about the what part, the more important aspect, IMHO, is about the why, i.e. the reasonings and insight behind it. For instance, remember I asked why you changed from NeoPixel to matrix LEDs? Is there some trouble using NeoPixel that I did not know about that I would learn a lesson from you? Or is it some trouble with using Arduino to drive NeoPixel, that I would not have to worry about? Why would you choose a string based protocol that is not exact the strong suit of embedded processors to parse. Is there a limitation in the DCS that you must use a string? I don't know the answers to those, so I asked why. As simple as that. I did say "That would have the same learning value, yet produce something more useful." Meaning, I do agree with you about the learning value of what you posted. But you seemed to have read the opposite. "more useful" -- meaning, what you posted is useful, but you could have done even better if you have made the board do things those two other boards I linked to could not. I don't know the answer to that, so I asked. As simple as that.

Why didn't you choose to make a board that is something you need and nobody else already made much better ones? That would have the same learning value, yet produce something more useful.

Why didn't you choose to make a board that is something you need and nobody else already made much better ones? That would have the same learning value, yet produce something more useful.

http://www.adafruit.com/product/2000 Yet another 1/2 the price, made in USA name brand board, not your Chinese clone, containing FTDI serial-USB chip and active power supply chip/circuit on board. Google is your friend.

USD $8.88, straight from the horse' mouth, Atmel the chip manufacturer, not your average Chinese clone. And it even got a power supply chip/circuit on it to stabilize the power for the MCU. It also contains an Atmel EDBG embedded debugger chip on board. http://store.atmel.com/PartDetail.aspx?q=p:10500392#tc:description

I think Milan is probably towing gliders in the Croatian Glider Championship. So, just a bit more patience.

Eeeerrrr..... Why wouldn't the Arduino shield you use work? I don't understand this sentence... what chip? One ATMega chip per string of NeoPixel? If you use the AdaFruit's extremely timing critical "demo" code for driving NeoPixel, indeed that would be the case. That code is so timing critical that even if you change the frequency of the CPU, it will break. And if you don't turn off the interrupts it will break too. It's only good for demo purpose, but people keeping using it. Check out this approach, http://www.pjrc.com/teensy/td_libs_OctoWS2811.html. And BTW, an NeoPixel costs USD $0.41, while an SMD LED could be had for USD $0.04, and a 5mm through hole LED is about USD $0.10 to $0.20. Even if you use 200 of them per pit, the price difference is minimal.

Why not? AdaFruit's code too timing sensitive? Unable to handle large number of NeoPixels? Why is the Max7219 a better solution?

Tiny open loop steppers, maybe.

Let me put it this way.... If the flower power artists can do Arduino and even write some code on it, you as pit builders have no excuse of saying this building/burning Hempstick from source code is too difficult. Remember, my intended audience is those people who tinker/build their pit/joystick etc., not the virtual aces, although they are welcome too. If the virtual aces don't wanna learn this technical stuff... so much better we nerds get to kick their asses in the air! Remember, if it's a fair fight, you didn't plan it right (or hack it right!).

No, I will not write a UI for configuring it or burning firmware through bootloader. Somebody else can write it, if they feel so urged to. Or get somebody else to burn it for you. Hell, buy one that is burned for you, if somebody wants provide such a trivial service and charge a fee for it. I do consider other method for configuring Hempstick dynamically, there are some very good ideas I could do, but this functionality has much lower priority than other core functionality Hempstick currently lacks. Releasing it as an OpenSource has its perks. Modify it as you wish. I made it easy to just change couple of configuration .h and .c file, you change it and you compile & burn the firmware yourself. That's why I spend so much time writing the User's Manual providing step-by-step instructions of the "screenshot digest" format. So you can install the IDE and tool chain yourself, load up the project, modify the config files, and then press just one button and the IDE will do everything including compiling/linking, upload and burn the firmware for you automatically. The IDE does a wonderful job at that. Why bother writing another application to upload and burn the firmware through the bootloader while the IDE does a better job? I actually consider this process better for an OpenSource one than using a bootloader. I'd rather spend my time ensuring that Hempstick is not a pig instead of putting lipstick on it. I am not saying writing a GUI is always lipstick, it's necessary for closed sourced ones, but not so much with an OpenSourced one. Yes, it's less user-friendly... if somebody else really wants it that bad, s/he can write it. I also intend to use this to "entice" people to learn this development process a little bit so they get their feet wet into this by start with modifying the configuration files a bit and then eventually starting writing things that they want themselves; or stay at the level of end user by downloading a set of config files created by others. Play with it, start your own project and create a set of your configuration files by modifying the existing one, then contribute it back to the community! For instance, if you don't want to use 1ms USB report rate, go change src/config/conf_usb.c inside the USB device descriptor to whatever value you want, then burn your own firmware. Or, if you get a set of config files that have cleaner wiring for, say Cougar Throttle, than mine, share your config files. In other words, b/c it's OpenSourced and the process of building/burning firmware is so easy, the Windows configuration GUI gets downgraded from "essential" to optional status, hence much lower priority.

Thanks for your kind words, Milan! Well said, Milan. That's exactly the strategy I took in Hempstick! ;-) I used an internal timer to trigger ADCs at a configurable frequency, at 1KHz x 4^n oversampling rate to match the 1ms USB reporting rate. And let the ADC run on its own pace at that rate. All 16 channels can be sampled by one timer trigger event. The ADC module will automatically sample all the channels I enable in one shot. Once it's all done, it does a DMA transfer to my designated buffer, and then issue an interrupt to my ADC interrupt handler, all done without intervention. The interrupt handler simply copies the data away from the buffer and reload the DMA buffer pointer preparing the buffer for next ADC trigger. Then it does a "give" on a semaphore to trigger a FreeRTOS task. And it returns immediately so that it doesn't hog the CPU in the interrupt handler for longer than it needs to. Then, the FreeRTOS task handling the ADC will get unblocked and scheduled to run by FreeRTOS to process the ADC values. This ADC task just does a decimation on the existing buffer of the running circular buffer and a running average low pass filter. Then it copies the latest values to the USB report and went back to blocking waiting for the next notification of ADC value availability. So, even if I have multiple ADC conversions during one USB report period, say due to CPU being too busy or FreeRTOS scheduling delay of the ADC processing, it will always report to the USB host the latest available values, never wait for ADC conversion to finish. The ADC conversions simply run independent of the USB reports. ;-) This way, the host computer always gets the latest of what you "feel" in your hand and is available for reporting, minimizing the delay as much as possible. I imagine it would be very hard to formally quantify the delay quality when it comes down to sub-10ms range without a rigorous large scale study. And I can't find any hard data on this subject. So, I took the safe route of over kill strategy since I got a lot of CPU power to bring to bear and Hempstick is an event-based architecture so it doesn't use any CPU cycle when there is no event to process. I give you 1ms USB reports, and the latest ADC/button values. So, that gives the upper bound of the delay to 1ms as well (as long as the ADCs don't take more than 1ms to sample all enabled channels and the CPU is not too busy; this is why I can only do 3x 16bit oversampled axes, because 4x would take more than 1ms to sample). Since I have a lot of CPU... I don't do adaptive anything. I just brute force it to keep the code simple and straight forward. ;-) In short, I basically ensure that the oldest report USB is going to get is 1ms old and it's the latest one, if the CPU is not overwhelmed.

The shift register chip, CD4021BC by Fairchild, used inside Cougar/Warthog is obsolete. Can't buy it anymore from regular channels. So, I found a replacement HCF4021 from ST. It runs up to 20MHz, although it only goes up to 10V instead of 15V, it's good for both 3.3V & 5V operations. It's so cheap that I had to order 100 of them ($19.40) and still couldn't justify the s/h, so I also ordered a bunch of MCP23S17 IO expander chips with SPI interface. We will see which one works out better. Maybe I will support both.

I didn't detect any criticism. I am a programmer by trade. I talk straight. CDU is a good example I didn't think of. Good point. My mistake. There are basically two approaches to solve this problem. 1. Brute force it. Get a bigger MCU with more leads. But that depends on the manufacturer, and it costs more money. Or get multiple $39 boards. This sucks. 2. Extend it to read more buttons other ways. The whole point of Hempstick is that we can extend it relatively easily. ;-) I'd say #2. Controlling one device with two boards is just stupid. There are basically two ways to solve this problem. A. Use a matrix. B. Use a buffer like TMStick does, or use a bunch of input extender chips like BU839X does. I'd go with B with buffers like TMStick has for two reasons. i). Hempstick already has a TMStick module to read the buffer with pure hardware. And it does software debounce on it already. And we know the hardware buffer solution has worked well for oh so last decade or more. ii). No diode to deal with., no ghosting either, and the wires number is ---- you guessed it, 5. Less wiring than a matrix solution. And less MCU pin demands too! The hardware cascaded buffer is so simple to construct, you can use a breadboard if you want. But I wouldn't recommend using breadboards, b/c if we drive the damned thing through a couple of MHz, you are going to run into trouble. Yes, even these old old chips can run into a couple MHz... I just felt it wasn't necessary to drive them that hard and ran them at a couple of hundred KHz. Moreover, the longer the wire the more problem there could be with higher frequency. But with more chips cascaded, you probably want to run them at higher freq. so it doesn't take too long to read. Hardware reads it anyway, it doesn't use more CPU at all (well, except that originally I copy three bytes, now I copy 16). There are two parts to this modifications. 1. Steal the TMStick code and you can construct a cascaded buffer just like TMStick has. Cascade it to infinity & beyond, ok. ok, up to 128. Cascading this thing longer than that is a bit crazy. But there is nothing stopping you from doing that. 2. Optional. If 128 is all you want. Change the USB report to be 128 instead of the current 64. Trivial. If you want more than 128, well, change the USB report to have to HID report descriptors, and then send back two reports. Each containing 128 buttons. This is not so trivial, but not exactly difficult. Very minimal amount of code change. Time to order a bunch of those buffer chips.

Absolutely no ATMegas! It defeats the whole purpose of using up-to-date electronics. ATMegas are too old as a joystick controller, so are a lot of the PIC MCUs used in today's joystick controllers. I wrote Hempstick mainly because I couldn't find one available on the market that is up-to-date and extendable. Why would I go backward? As to 256 buttons... then I must ask this question. Why stop at 256? How about 1024, i.e. 8x composite joystick controller all in one physical controller? Is 1x 256 buttons controller better than 4x 64buttons $39 controllers? In what way? To really understand why there is a limitation on how many buttons Hempstick is WILLING to handle, you have to understand event-based architecture Hempstick uses. I am writing an article about it right now that will explain why you don't want to use the old way of busy polling that everybody seems to be using, except a few newer ones. Hang tight.

However, let me give you a little warning about using Target with Hempstick. Any USB firmware can do it, not just Hempstick. it's dead simple. No code modification needed. If TM is unhappy about it, they can take it out anytime they wish. As somebody who makes a living out of programming, I fully respect their right to do whatever they wish with their software so I have no intention of circumventing that. Use it at your own risk. However, if they want to take it out. They would have to do the followings. 1. Update Target. 2. Probably also update the drivers. 3. Update the firmware to match the driver change. #2 & #3 above apply to all TARGET supported devices, including MFDs, Cougar, T.16000M. So, as long as you don't update your TARGET and Driver... it will continue to work. Now legality warning. It may be illegal to divulge how to make any non-TM-made controller to work with TARGET, due to DMCA. Although it may be perfectly legal to program Hempstick this way, it may violate your license agreement with TM for using TARGET in this manner. I am not a lawyer, but you have been warned.

You read that right. I did that with my my Cougar-in-pieces too. Of course there are limitations... there is no composite keyboard/mouse thing that Cougar does. You just get a bunch of buttons/axes that you can use inside TARGET and program them. But, that's all you need. You don't need those stinky virtual mouse/keyboard thing with TARGET. TARGET does that for you anyway. You can't program Hempstick with Foxy either because I didn't implement any Cougar-specific settings like axis curving/button mapping thing that used to be stored on Cougar firmware. Why bother doing that anyway, it's a horrible way of doing things while you can do the same thing in TARGET. TM at least made a very good choice of moving this kind of stuff into TARGET instead of having it done in the firmware (both commercially and technically). If you do embark on such a project. Let me know, I will help you produce a better mapping configuration so it's a lot easier to wire up (I use the ball of wires method, but it's possible to use a ribbon cable to make it neater and easier).

If it's just generating straight keystrokes, yes I will add that sometime in the future. It will just behave like a straight keyboard and you can use it to build a hell of a keyboard -- every key hooks up directly to an MCU pin, all hardware debounced, absolutely no matrix, thus absolutely no ghosting. But, unless you have a custom board, there are not enough pins brought out to build a full keyboard, This is mainly intended for input like radio keypad input etc. I mean, you could use button for these, but if it's a keyboard, why not make it a keyboard.

On Resolution Here's an article I just wrote about controller resolution... http://www.hempstick.org/download/articles/OnResolution.pdf. In view of so much interests in the pursuit of higher and higher resolution, I attempt to rationalize why I limit the resolution of Hempstick to 14bit. And to, again, dispute the 16bit resolution myth of the Warthog (damn it, this thing just won't go away!). You be the judge.

Pre-Configured File Sets From now on, Hempstick will come with sets of pre-configured configuration files. It will be located in src/config/..., for instance, src/config/Cougar/. You just pick the set you want, copy all the files in there to src/config/ overwriting whatever is there and compile and burn the firmware. If you have a set that you wish to contribute and share with others, please let me know, I will put it up to the official release.