Biggus

@Sergey_Pe Thanks for the response and the suggestion of an STM32. I've got one in my stash waiting for a project, and I think you're right, it's a better choice for this job. I'm redesigning my PCB now.

I've built boards with MMJoy2 before successfully, but I'm about to create a slightly more complex board and although I've found fragments of helpful information, I still have a few questions before I send my PCB to the manufacturer. The first question: Can I connect encoders to shift registers? And if I can, do they still need diodes? My second question comes from some confusion as the only example schematic I've seen only includes the Pro Micro and an MCP3008, and in that diagram, the D-OUT for the MCP3008 is connected to the MISO pin. Is D-OUT intended to be shared with the MISO pin for the shift registers? I don't think it is, but I'd really like to get a second opinion. Any help would be greatly appreciated.

I suspect they'll start with a J because of the Forrestal. Js served on the Forrestal until 1981-82. There were actually Js operating in the Med during the first Sidra incident. A Super J would be nice but I don't think they ever went to sea.

I'd love a Midway but I think it's a bit much to ask, considering the effort and time that went into the Forrestal. A Midway would certainly give the S model more longevity at sea for historical scenarios.

I had this feeling an announcement was coming. The effort going into the Forrestal for what was implied to be more than the Tomcat and Intruder, the unnamed module on the Trello, the work that HB has put into the AI RIO. I'm excitedly awaiting what I will assume will be an F-4J and possibly an S following the E, but I'll be buying everything HB puts out. Even if that includes an RF-4. I couldn't be more thrilled that it's HB doing it.

It's gotten quite a bit worse for me this patch, although I did take a bit of time off during the one prior. Occasionally the box will stay on the screen. Hitting one of the view keys seems to get rid of it.

I certainly see EGIW from time to time with full mil on touchdown. I suspect that the call is sometimes being made a fraction of a second earlier than it should. It's certainly better than it used to be though.

I have the same issue at gamma 2.2. Actually the front seat radio display is probably the more frustrating of the things that have this problem. I'd love something like a toggle to shade areas under the mouse, like a reverse flashlight.

Yup, no issues with trim here. What I do have an issue with is that if you aren't quite within the parameters for the alt hold to engage, pressing the NWS button to engage it seems to generate a pitch-down moment.

Thank you for not only the skins, but the time and effort and skill and attention to detail that you put into them! Is there any chance that you could create a single file with all your skins? I know it would be quite large, but it would be significantly more convenient.

Yeah, I'm seeing a pitch down on any failed attempt to engage alt hold AP.

My system isn't that different. 3070, 32GB of 3600mhz ram and a 5800x. I agree that the carrier performance is probably in need of some tweaking. That tiny stutter is literally at the worst possible time. If it happened literally a second, maybe 1.5s later it would be much less noticeable as the plane hits the deck and decelerates (although it'd still be annoying with bolters and touch and go stuff).

I experience this pretty regularly. It's almost like there's a LOD change when it happens.

LSO callouts for the Tomcat are still wrong.

It's beautiful. The smoke really adds atmosphere when you're recovering. LSO telling me I'm slow when I'm on-speed. I assume it's an ED problem, and a very old and frustrating one at that.

I've seen it for the last few months. Steps to reproduce. 1. Join MP server. 2. Select Hornet slot, start and launch for mission as per usual. 3. Die. 4. Respawn. At this point, I generally find myself attached to the cat with chocks in place and there is nothing to do but re-slot. Admittedly I haven't tried it in the current OB patch, but prior to that it was a pretty regular occurrence for myself and many I fly with.

I'd agree that most of the first hand accounts of head-on Sparrow shots I've read lead me to believe that they are somewhat underperforming in terms of range. They might just be a bit better in terms of seeker performance in DCS than they are in reality though. I'd assume it will be looked at by ED at some point.

To be fair, you've made quite a few of us a bit more educated and smarter.

I'm quite space-constrained, so no cockpit for me. I'm jealous of the quality of the work on display in this thread though! I am building switch panels that are more for quality of life than a true 1:1 reflection of reality, but I'm mostly using PCBs to do it. I print a basic enclosure and mount the PCB to it. They're not pretty, but they work well enough, are cheap, do not take up too much desk space and are fast to design. My Jester control board has been revised a few times now, as I've added features, taken away features, changed layouts, and finally changed from a Pro Micro running Mmjoy2 to a Raspberry Pi Pico running a modified sketch based on the Real Robots Configurator. If I was going to build a cockpit, I'd be inclined to stick with the Pro Micro due to the ease with which you can add shift registers, but being able to mount the Pico directly to the PCB via castellated holes (not to mention price and availability) inspired me to change hardware. I'm not quite finished building the display control panel, as I'm not happy with these particular switches. But I'm pretty happy with how the panels have turned out so far. Next panel is going to be for the AP panel (and I'll add an O2 switch and ejection seat arming switch because VR and lazy).

There are no guarantees that the switch symbology matches the actual limitations.

I'm absolutely not any kind of signals engineer at all, but I believe it's PRF eclipsing. The radar return is happening whilst the radar is in the transmit part of it's cycle rather than in the receiving part of the cycle. This is probably a grossly simplified explanation, but that's why the radar has limits on the closure it can work with. It is apparently less of an issue with pulse mode however that's not really particularly helpful when launching 54s.

Plenty of reactions. Most of us I think are content to leave it to HB to address this, with presumably the full unredacted report. I agree it's an excellent investigation.

Our current work around is for the idiot in the front to make a ker-chunk sound effect.

I find that the button inputs don't work for elevation, but having it on an axis certainly works for me.

Great bunch of skins. Thank you very much!