[{"content":" Keppytronics Services Engineering consulting for digital electronics\nOverview I founded Keppytronics after twenty years of industry experience building avionics for cubesats and smallsats. During that time, my role combined leadership of small ad-hoc engineering teams with hands-on development of bespoke hardware, gateware, and software. I was closely involved in all stages of the product life-cycle including concept, architecture, design, development, board bringup, debugging, verification, and maintenance of fielded systems.\nMy deepest expertise is in firmware and gateware development. I am an expert in VHDL and C++, and proficient in many other programming languages including Java, MATLAB, Python, and Rust. I am most comfortable on bare-metal embedded systems, but have experience working within FreeRTOS and Linux.\nI routinely work with cross-disciplinary teams (electronic, mechanical, optical, power, thermal, etc.) to solve difficult technical problems. I am not a specialist in those domains, but I know enough to communicate effectively, coordinate teams, and mediate when conflicts arise.\nThis page lists my areas of expertise. If your project needs help in any of these areas, please contact Keppytronics to set up a consulting or support contract.\nSatCat5 SatCat5 is a free and open-source Ethernet switch published by The Aerospace Corporation. I was the principal investigator for the SatCat5 project from its inception in 2018, until I left Aerospace to found Keppytronics LLC.\nSatCat5 started with a focus on gateware, with a standalone Ethernet switch that can be instantiated on several field programmable gate array (FPGA) platforms. Over time, the project added software-based features for switch-management and remote-control functions, which eventually grew into a cross-platform framework for embedded software. Over time, the project added a gateware-accelerated IPv4 router, MACsec encryption, and a software-defined IP/UDP stack supporting ARP, CoAP, DHCP, ICMP, NTP, TFTP, and other protocols. SatCat5 also offers best-in-class support for Precision Time Protocol (PTP), achieving picosecond-scale time-transfer over asynchronous Ethernet networks.\nThough SatCat5 was originally intended for small-satellite applications, it\u0026rsquo;s also well-suited for commercial and industrial applications on the ground. SatCat5 excels in bridging the communications gap between powerful computers and resource-constrained embedded microcontrollers.\nFPGA \u0026amp; Gateware Development I have been performing hands-on FPGA development throughout my entire career, covering the entire life-cycle for a given project from inception to hardware delivery, including support for products deployed remotely to a customer laboratory or to orbit.\nI have extensive experience developing complete FPGA systems on multiple FPGA platforms. I\u0026rsquo;ve worked with Xilinx parts (6-series, 7-series, Ultrascale, Zynq SoC), Microchip (RTG4, Polarfire), and Lattice (iCE40).\nAt the lowest level, I frequently develop and validate gateware designed for a specific purpose:\nDigital signal processing, including multi-rate filters and adaptive filters Clock domain crossing (CDC) for asynchronous, plesiochronous, and synchronous systems Ethernet media independent interfaces (RMII, RGMII, SGMII) Ternary content addressable memory (TCAM) for MAC-address and IP-address lookup. At the higher level, I develop software to support all operations of the complete system. This includes software for embedded soft-CPU or hard-CPU microcontrollers, such as device-drivers to allow software control of gateware functions. I also develop command, control, and telemetry tools to allow users to test and operate the FPGA system, using frameworks such as COSMOS/OpenC3 or custom console and GUI applications.\nSignal Integrity I have experience solving signal integrity problems for high-speed digital signals up to about 10 Gbaud. I can review PCB, cable, and connector designs to spot and fix potential problems before they strike. I can also perform diagnosis and troubleshooting after the fact. I have relevant design and troubleshooting experience with several generations of FPGA-based SERDES transceivers.\nTime Transfer Time transfer is the process of precisely synchronizing a local clock to another reference clock, often over considerable distance using wired or wireless communication links. Time transfer with sub-nanosecond accuracy is a backbone of GPS/GNSS systems, scientific instrumentation, and even some financial systems.\nI developed the Precision Time Protocol (PTP) subsystem for SatCat5, including invention of the vernier-referenced digital asynchronous collinear timestamp (VERDACT) circuit. VERDACT is a patented digital circuit for generating high-precision digital timestamps. Unlike other state-of-the-art time-measurement circuits such as DDMTD, VERDACT can be applied to asynchronous clocks, i.e., free-running digital clocks that have no common frequency or phase reference. Timestamps in different clock domains can be compared by simple arithmetic and maintain sub-picosecond precision.\nDigital Signal Processing I have extensive experience designing and implementing digital signal processing (DSP) using FPGAs, including software-defined modems for radio-frequency and free-space optical communication. This includes implementation of massively parallel mixed-rate and variable-rate designs, such as fractional resampling filters for symbol timing recovery in software-defined radio receivers.\n","permalink":"https://keppytronics.com/services/","title":"Services"},{"content":" About Keppytronics Keppytronics LLC Keppytronics LLC is a one-man engineering consulting company registered in Hawthorne, California. It was founded by Alexander C. Utter in 2026.\nFor additional information about the company:\nContact information Our services Privacy policy Alexander C. Utter Alex Utter received the B.S. degree in engineering from Harvey Mudd College and the M.S. degree in electrical engineering from Stanford University in 2007.\nFrom 2005 to 2025, he worked at The Aerospace Corporation, leading development of FPGA-based avionics used on more than a dozen cubesat missions. During that time, his major projects included the SatCat5 open-source Ethernet switch, the Slingshot-1 cubesat, the AeroCube camera, and modems for free-space optical communication. Alex is the listed inventor for seven US patents, including the VERDACT circuit for precision timestamps.\nAlex is the founder and sole member of Keppytronics LLC.\nAlex\u0026rsquo;s latest resume can be found here.\nKepler Kepler is the cutest cat to ever exist! She puts the \u0026ldquo;Kep\u0026rdquo; in Keppytronics.\nPublications A selection of Alex Utter\u0026rsquo;s scientific publications:\nAlexander Utter and Joseph Zales. \u0026ldquo;Precision Time Protocol at Picosecond Scale Over Asynchronous Ethernet.\u0026rdquo; 2025 IEEE Aerospace Conference.. Alexander Utter. “Beyond DDMTD – Sub-Picosecond Timestamps for Asynchronous Clocks.” IEEE Access 2023. doi: 10.1109/ACCESS.2023.3345833. Hannah Weiher, Dan Mabry, and Alexander Utter. “Slingshot: In-Space Modularity Test Platform.” AIAAA SciTech 2022 Forum. Alexander Utter, Mark Zakrzewski, Andrew Keene, Samuel Dietrich, Sammy Lin, Eric McDonald, Nathan Whitehair, and Jason Zheng. “SatCat5: A low-power, mixed-media Ethernet network for smallsats.” AIAA/USU Smallsat Conference 2020. Darren Rowen, Alexander Utter, et al. \u0026ldquo;On-orbit Results from an Ultra-low SWaP Black Silicon Star Tracker.\u0026rdquo; AIAA/USU Smallsat Conference 2020. Eugene Grayver, Alexander Utter. “Extreme Software Defined Radio—GHz in Real Time.” IEEE Aerospace Conference 2020. David Allen, Alberto Arredondo, John Betz, Alessandro Cerruti, Benjamin Davidson, Karl Kovach, and Alexander Utter. \u0026ldquo;Effect of GPS III weighted voting on P(Y) receiver processing performance.\u0026rdquo; Journal of the Institute of Navigation 2020. Richard Welle, Alexander Utter, Todd Rose, Jerry Fuller, Kristin Gates, Benjamin Oakes, and Siegfried Janson. \u0026ldquo;A CubeSat-Based Optical Communication Network for Low Earth Orbit.\u0026rdquo; AIAA/USU Smallsat Conference 2017. Darren Rowen, Alexander Utter, Richard Dolphus, and Eddson Alcid. \u0026ldquo;A Miniature, Low-Power Star Tracker for Precision Pointing Nanosatellites.\u0026rdquo; AAS Guidance and Control Conference 2015. Alexander Utter, C. E. Edgar, T. D. Powell, and P. A. Dafesh. \u0026ldquo;Cyclostationary Analysis of SVN-49 Signal Distortion.\u0026rdquo; ION Technical Meeting 2011. Alexander Utter, Henry Chen, Shane Ouchi, David Money Harris, Amanda Rainer, Keane Kaneakua, Chris Prounh, and Samuel S. Osofsky. \u0026ldquo;Adaptive two-channel automatic gain control system.\u0026rdquo; IEEE Aerospace Conference 2006. Patents A selection of patents where Alex Utter is the listed inventor.\nPatent US12107589B2 “Vernier phase locked loop” Patent US12063068B2 “Tracking system” Patent US11055254B2 “Mixed media Ethernet switch” Patent US10996340B1 “Tracking system” Patent US10340962B2 “Amplitude domain circuits\u0026hellip;for reducing an interference signal” Patent US9092371B2 “Signal parameter estimator” This Website This website was created using Hugo with the MIT-licensed Monochrome theme and Mono-Icons.\n","permalink":"https://keppytronics.com/about/","title":"About"},{"content":" Contact Information If you have a job for Keppytronics, or you have questions about what we can do for you, please reach out. If you are marketing your own services, please don\u0026rsquo;t.\nEmail (preferred): keppytronics@protonmail.com Phone: 213-993-0194 (Monday through Friday only, 10am - 5pm Pacific) Social: GitHub, LinkedIn ","permalink":"https://keppytronics.com/contact/","title":"Contact"},{"content":" Keppytronics LLC Privacy Policy Last Updated: 2026 June 25, 2026\nAt a Glance: Keppytronics LLC will never sell your personal data. If you provide data to us, we use that data to deliver our professional services and communicate with you. We share data only with essential service providers (like secure hosting and payment processors) needed to run our business.\nIf we have questions, you can reach us anytime at keppytronics+privacy@protonmail.com.\nWhat We Collect \u0026amp; Why Information You Give Us Directly When you reach out for a consultation or sign up for our services, you voluntarily provide us with personal details. This typically includes your name, email address, phone number, and any business context you share in your messages.\nWhy we need it: We cannot communicate with you or deliver our consulting services without this information.\nLegal basis: Processing this data is necessary for the performance of our contract with you, or to take steps at your request before entering into a contract.\nInformation Collected Automatically As you navigate keppytronics.com, our systems automatically log certain technical details. This includes your IP address, browser type, and basic interaction data (like which pages you visit).\nWhy we need it: This data helps us understand how our website is performing, catch technical errors, and prevent malicious activity.\nLegal basis: We rely on our legitimate interest in maintaining a secure, functional, and optimized digital presence.\nInformation from Third Parties We occasionally receive information about you from trusted third-party partners. For example, if you pay for our services online, our payment processor will send us a confirmation that includes your billing details (though we never see or store your full credit card number).\nWhy we need it: To verify transactions and ensure your account is properly credited.\nLegal basis: Performance of a contract and our legitimate interest in managing our financial records.\nHow We Use Your Information Core Service Delivery Our primary use of your information is to perform the work you hired us to do. We use your contact details and business information to provide our consulting services, manage your account, and fulfill our contractual obligations to you.\nCommunication We will use your email address or phone number to send you important administrative updates, respond to your inquiries, and send invoices. These communications are necessary to negotiate and complete a contract.\nSecurity and Fraud Prevention Protecting our infrastructure is critical. We monitor technical logs and user behavior to detect, prevent, and respond to potential security incidents or fraudulent activity. This processing is grounded in our legitimate interest in keeping our platform and our clients safe.\nLegal Compliance Sometimes the law requires us to process or retain certain information. For example, we must keep accurate financial records for tax purposes. In these cases, our processing is based on a strict legal obligation.\nWhen We Share Your Information We treat your data with strict confidentiality. Keppytronics LLC does not, and will not, sell your personal information to data brokers, advertisers, or anyone else. We only share your data in the following limited circumstances:\nEssential Service Providers To run a modern consulting business, we rely on carefully vetted third-party tools. We share information with secure hosting providers that keep our website online and payment processors that handle our billing. These providers are legally bound to protect your data and can only use it to provide their specific service to us.\nNo mobile information will be shared with third parties/affiliates for marketing/promotional purposes. All other categories exclude text messaging originator opt-in data and consent; this information will not be shared with any third parties.\nLegal Requirements If we receive a valid legal request, such as a subpoena or court order, we may be required to disclose certain information. We will only share what is strictly necessary and, whenever legally permitted, we will notify you before handing anything over.\nBusiness Transitions If Keppytronics LLC is ever involved in a merger, acquisition, or sale of assets, your information may be transferred as part of that transaction. We will ensure that any acquiring entity respects the commitments made in this Privacy Policy.\nWith Your Consent For any situation not covered above, we will ask for your explicit permission before sharing your personal information. You always have the right to say no.\nYour Privacy Rights Depending on where you live, you have powerful rights regarding your personal data, particularly under the CCPA/CPRA in California, as well as laws in Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), and other states. We extend these core rights to all our users, regardless of their location.\nRight to Access: You can ask us for a copy of the personal information we hold about you. We will provide this within 45 days of a verified request. Right to Correction: If you spot a mistake in your data, let us know and we will update our records promptly. Right to Deletion: You can request that we erase your personal information. We will honor this request unless we have a legal obligation to keep the data (like tax records) or need it to complete a transaction you requested. Right to Data Portability: You can ask for your data in a structured, commonly used, and machine-readable format so you can transfer it to another service. Right to Opt-Out: You can easily opt out of any marketing communications by clicking the \u0026ldquo;unsubscribe\u0026rdquo; link in our emails. Right to Withdraw Consent: If you previously gave us permission to process your data, you can change your mind at any time. This won\u0026rsquo;t affect any processing that happened before you withdrew consent. Right to Non-Discrimination: We will never charge you different prices or provide a lower quality of service just because you exercised your privacy rights. To exercise any of these rights, please email us at keppytronics+privacy@protonmail.com. If you feel we have not addressed your concerns, you also have the right to lodge a complaint with your state\u0026rsquo;s Attorney General or relevant data protection authority.\nData Security We align our security practices with rigorous industry standards. While we work tirelessly to protect your information, we cannot guarantee absolute security.\nYou also play a role in keeping your data safe. We encourage you to use secure networks when communicating with us and to be mindful of the information you share over unencrypted email. In the unlikely event of a data breach that compromises your personal information, we commit to notifying you and the relevant authorities within the timeframes required by state laws.\nData Retention We do not hoard data. We keep your personal information only for as long as we have a legitimate business need to do so.\nActive Client Data: We retain your contact and project information for the duration of our consulting relationship, plus a reasonable buffer period to accommodate follow-up questions or returning business. Financial Records: By law, we are required to keep invoices, payment records, and related financial data for up to 7 years for tax and accounting purposes. Marketing Preferences: If you opt out of marketing, we keep a minimal record of your email address indefinitely simply to ensure we respect your \u0026ldquo;do not contact\u0026rdquo; request. Technical Logs: Routine server and security logs are typically automatically overwritten or deleted within 12 months, as they lose their security relevance after that time. Cookies \u0026amp; Tracking Like most websites, keppytronics.com uses cookies (small text files placed on your device) to make our site work properly and help us understand our traffic.\nWe use essential cookies that are strictly necessary for the website to function (such as remembering your session). We do not intentionally use cookies for analytics.\nYou have control over this tracking. Most web browsers allow you to manage your cookie preferences, including blocking them entirely or deleting existing ones. Please note that disabling essential cookies may impact how our website functions for you.\nChildren\u0026rsquo;s Privacy Our professional consulting services are designed strictly for businesses and adult professionals. We do not knowingly collect, solicit, or maintain personal information from anyone under the age of 13 (or under 16, as applicable under the CCPA).\nIf you are a parent or guardian and believe your child has provided us with personal information, please contact us immediately at keppytronics+privacy@protonmail.com. If we discover that we have inadvertently collected data from a minor, we will take swift action to delete that information from our servers in compliance with the Children\u0026rsquo;s Online Privacy Protection Act (COPPA).\nInternational Transfers Keppytronics LLC is based in the United States, and our servers and service providers are primarily located here. If you are accessing our website or services from outside the US, please be aware that your information will be transferred to, stored, and processed in the United States. By using our services, you understand that your data is subject to US laws, which may offer different privacy protections than those in your home country.\nChanges to This Policy Privacy laws and business practices evolve, and this policy will occasionally change to reflect that. When we make updates, we will revise the \u0026ldquo;Last Updated\u0026rdquo; date at the top of this page.\nIf we make material changes to how we handle your existing personal data (such as using it for a new, unstated purpose) we will provide fair notice by emailing our active clients or posting a prominent banner on our website before the changes take effect. We encourage you to review this policy periodically to stay informed about how we protect your privacy.\nContact Us We welcome your questions, feedback, and requests regarding this Privacy Policy. If you need to reach out, you can contact our privacy team at keppytronics+privacy@protonmail.com.\nWe monitor our privacy inbox closely and aim to respond to all general inquiries within a few business days, and to formal privacy rights requests within the legally required 30 to 45-day timeframe.\n","permalink":"https://keppytronics.com/privacy/","title":"Privacy Policy"},{"content":"As I mentioned in the earlier post, being able to daisy-chain devices is an important goal of the star tracker project. Longer term, I want this to be an entry point to a broader family of small-satellite modules built around SatCat5.\nBy \u0026ldquo;daisy-chain\u0026rdquo;, I mean there\u0026rsquo;s an upstream host that provides power and data to the first module. The first module is connected to the second, the second to the third, and so on up to some reasonable limit. In a satellite, the host is probably the vehicle\u0026rsquo;s flight computer. On a lab bench, the host is probably a dongle attached to a regular PC. Let\u0026rsquo;s assume for now that all the modules are star trackers:\nThe advantages of the daisy-chain interface are that the host only needs to supply a single port, there\u0026rsquo;s less cable weight than a star topology with a central hub, and it\u0026rsquo;s easy to add more modules to an established design.\nThe disadvantage with a daisy-chain interface is that all modules in the chain share resources. That means if one fails, everything further down the chain will lose communications. (Connecting everything in a ring could add some redundancy to mitigate that concern.) The chain topology also means that whatever design choices we make now will forever constrain the types of future modules that can maintain compatibility. In terms of power, star trackers will draw about 1 to 2W each when active, but a radio could easily consume 5-10W, and power-heavy modules like a GPU might draw 30W or more. Similarly, star-trackers that handle image-processing internally will need very little data (say 50 kbps each), but what about a larger network? A chain with five star trackers, a few reaction wheels, and a radio could be satisfied at 1 Mbps. A chain that\u0026rsquo;s streaming video data from a camera module to a GPU module could easily consume 1 Gbps or more.\nIn any case, here\u0026rsquo;s a block diagram showing the inside of each star tracker module:\nIn this design, power flows through the chain as a single power rail and return rail, with local modules tapping off their own power as needed. Within defined limits, hosts would pick a supply voltage at design time, based on what\u0026rsquo;s convenient and the maximum expected power draw of attached modules. Remember: cables and connectors have current limits, not power limits per se, so maximum power delivery is proportional to the supply voltage.\nFor compatibility with various hosts, modules should accept the broadest practical input range. Depending on size, smallsats often have power systems at 5V, 12V, 24V, 28V nominal. Those voltages may be regulated, or they may vary with battery state. Ideally, modules would be able to accept any of these with comfortable margin, but wider ranges increase power supply complexity and decrease worst-case efficiency. A range of 4V to 32V might be a reasonable compromise, though increasing the upper limit to 48V would match common standards like PoE and the latest versions of USB-C power delivery. (I definitely wouldn\u0026rsquo;t want something as complicated as USB-PD on a critical spacecraft bus, but compatibility with widely-available power bricks increases low-cost accessibility for development hardware on the ground.)\nData flows through the chain one hop at a time, using an Ethernet switch on each module. To avoid breaking the chain, this part of the FPGA will need to be powered and running at all times, even when the rest of the module is asleep to save power. Use of Ethernet means that any module can talk directly to the host or to any other module in the chain, which is a big advantage over USB.\nOne big question is what flavor of Ethernet should be used for the chain. For future-proofing, it should be at least 10 Mbps, preferably 100 or 1000. Options such as 100BASE-T1 are appealing (bidirectional data over a single coax connector, wow!) but require a lot of power. At time of writing, a quick survey of available PHYs showed 180 - 500 mW per chip, and each module would need two. Since the entire chain needs these to operate even when the module is asleep, this would be unacceptable. Standards like LVDS or RS-422 would be more practical.\nThe other big question is connector(s). Connectors set a lot of important tradeoffs for physical robustness, size, maximum current, and signal integrity concerns. Having a single connector for power and data is convenient, but results in other unpleasant tradeoffs. Candidates include:\nHarwin Gecko: high current per pin, lots of backshell and retention options, poor high-speed signal integrity Samtec ARC6 or ARM6: excellent high-speed signal integrity, power would need to be a separate cable SATA: excellent high-speed signal integrity, inexpensive connectors and cables, power would need to be a separate cable USB-C: excellent high-speed signal integrity, inexpensive connectors and cables, limited mechanical robustness In conclusion: The daisy-chain concept can work, I have a decent idea of the design tradeoffs, and have some design decisions to make. Lots to think about.\n","permalink":"https://keppytronics.com/blog/star_daisy/","title":"Star Tracker: Daisy Chain"},{"content":"For the new workstation dedicated to Keppytronics consulting work, I chose Ubuntu 26.04 LTS.\nLong story short, I\u0026rsquo;ve mainly been a Windows user since childhood, starting with Windows 3.1. Looking back, I think everything since Windows 2000 has been a mistake, slowly ramping up the heat like the usual frog-in-boiling-water metaphor. Windows 2000 was great, Windows XP was fine, Windows 7 was OK, Windows 10 got on my nerves, and Windows 11 was intolerable. Every little thing was too slow, too web-obsessed, too privacy-invasive, too pushy about AI. When every patch makes things worse, I know I\u0026rsquo;m not in their target audience anymore. Unless Microsoft completely changes its tune, I\u0026rsquo;m never giving them another dime if I can help it.\nI dabbled in various flavors of Linux over the years, but used Windows for my primary machine until 2025. That\u0026rsquo;s when I switched my gaming PC to Ubuntu 24.04 LTS. After some initial pain with NVIDIA drivers, it\u0026rsquo;s been an absolute joy. Everything I need either \u0026ldquo;just works\u0026rdquo; or can be fixed with guidance from StackOverflow. I\u0026rsquo;d forgotten how liberating it feels when software actually respects its users and prioritizes performance over pushy marketing.\nWhen I purchased a workstation specifically for consulting work, I naturally chose Ubuntu again. The 24.04 installer didn\u0026rsquo;t work with the new GPU, so I upgraded to 26.04. My thoughts:\nThe easy option for full-drive encryption was a big plus. I previously used Veracrypt to secure confidential documents, but a blanket policy of \u0026ldquo;just encrypt everything\u0026rdquo; is much simpler and easier in practice. Official NVIDIA drivers were dead on arrival. Every version I tried resulted in black screen on boot, even with nomodeset and related flags. The simplest workaround was to choose the open-source Nouveau GPU drivers during the initial install. I will need to revisit this if I ever need CUDA support for a work project. Rebooting repeatedly to test GPU drivers (see previous bullet) is a time-consuming pain. It\u0026rsquo;s made worse when GRUB automatically boots to a broken black-screen configuration, the time window for various keyboard overrides is short, and the mainboard requires me to hold the power button for ten full seconds for a forced shutdown. (I\u0026rsquo;m not bitter. 😅) To make fixes easier, open /etc/default/grub and set options GRUB_TIMEOUT=3 and GRUB_TIMEOUT_STYLE=menu to give yourself a few seconds to make changes with minimal impact during normal operation. On that note, I\u0026rsquo;ve had problems with GRUB being unresponsive on 4K monitors. This can be fixed by setting GRUB_GFXMODE=1280x1024x32,auto to set a more reasonable resolution with a decent response time. In other news, the new business cards arrived. ","permalink":"https://keppytronics.com/blog/ubuntu26/","title":"Ubuntu 26.04"},{"content":"In short, I will not be integrating LLMs into my workflow for the foreseeable future.\nMy objections at this time are a combination of ethical, strategic, and practical concerns.\nFirst, I have ethical objections to the wholesale scraping of all human art, literature, and software. In particular, open-source code must inherently be available to the general public, leaving it widely available to be scraped for training, giving it a disadvantage against proprietary software. Many models can and will regurgitate large portions of that training data, with no credit or royalties to the original source. Though it would be absolutely hilarious if a court ruled that ChatGPT was violating GPLv2, regurgitated code is likely free of the original license terms.\nThis whole situation reeks of theft, even as current law allows it to continue. Meanwhile, the big AI companies call for government intervention when other companies use their AI\u0026rsquo;s outputs to train a new model. I cannot comprehend this level of hypocrisy and entitlement.\nSecond, I have strategic objections to the level of control being handed to a small handful of technology megacorporations. I have a strong desire to control the tools that I use. Given a choice, I strongly favor open-source over proprietary tools. Given a choice, I strongly favor a one-time purchase over subscriptions. Given a choice, I strongly favor locally-operated to cloud-hosted services. Recent increases in subscription fees and cost per token are a perfect example of why this type of control matters, as are recent attempts to block AI services across national borders.\nI do compromise the above where needed. At time of writing, hosting of this website is currently through Dreamhost, using open-source site-generation tools. My willingness to compromise depends mainly on how important a given tool is to my life and my livelihood. Because software development is extremely central to both; I will not violate core tenets except under duress.\nThird, I have practical concerns about sycophancy and confabulation. As many have noticed, LLMs tend to praise the user (\u0026ldquo;You\u0026rsquo;re absolutely right\u0026hellip;\u0026rdquo;) and confidently present misinformation and falsehoods (aka \u0026ldquo;hallucination\u0026rdquo;). I have my suspicions about the root cause for this, possibly a combination of bias in the RLHF process combined with inherent limitations of models based on next-token prediction. In any case, this problem hasn\u0026rsquo;t been solved by any of the major AI firms despite massive efforts; they may never be able to do so.\nFinally, I have practical concerns about code quality. From conversations with others who have embraced AI tools for software development, it\u0026rsquo;s clear that current tools need significant hand-holding and code review to get good results. It\u0026rsquo;s not clear to me how much these limitations are inherent to the technology and how much are linked to the confabulation problem, but that\u0026rsquo;s someone else\u0026rsquo;s problem. For my customers, reliability and quality tend to matter much more than features and schedule.\nI am attempting to remain rational about this. (Though bad behavior of big AI firms and obsessive media coverage sometimes make me want to pick up a pitchfork and shout, \u0026ldquo;Thou shalt not make a machine in the likeness of a human mind!\u0026rdquo;) For now, I am continuing to watch LLM and AI developments. If I can find an ethically-trained and locally-hosted model with good quality code output, I will give it a try. Until then, Keppytronics remains AI-skeptical.\n","permalink":"https://keppytronics.com/blog/ai_thoughts/","title":"Keppytronics and AI"},{"content":"Over the next year, one of the side projects I\u0026rsquo;d like to build is a prototype star tracker for cubesats.\nWhile I worked at The Aerospace Corporation, one of my ongoing cubesat projects was development of the star-tracker first used on OCSD (AeroCube-7). In short, it was an FPGA board that could take in video streams from several cameras and do various things with the data: such as store an entire frame as RAW or JPEG, capture a video stream, co-add consecutive frames, apply adaptive thresholds to detect bright objects, etc.\nI was never fully satisfied with the performance of that system. In particular, baseline power consumption was always higher than I would like, but there was never time or money to re-architect it. The system could execute very demanding tasks (e.g., full uncompressed video capture of multiple concurrent HD video streams), but the inherent hardware overhead made it unwieldy for for a lighter workload.\nMore recently, I had some ideas for a streamlined system design that would substantially reduce size, weight, and power when operating as a star-tracker. Ideally, the complete package wouldn\u0026rsquo;t be much larger than the sensor and optics.\nBuilding such a prototype seems like a good way to keep my skills fresh between client projects. To stay focused on the digital electronics, the prototype will be built around a pre-assembled SiOnyx camera module with a lens. Just maybe, if the prototype works well and I can find a buyer, it might make a good standalone product line.\nThe general idea is to cut the features down to the bare essentials and integrate the electronics, focal plane, and optics tightly into a single compact package.\nCutting features would allow a massive simplification to the video-processing pipeline. Most importantly, routine operation shouldn\u0026rsquo;t require a full-frame buffer. If the only real-time processing step is to apply a luminance threshold, then buffer requirements drop from megabytes to kilobytes, eliminating the need for external DRAM. If PCB space allows, a much smaller SRAM or PSRAM would still be useful for full-frame diagnostics, but that subsystem could be shut down to save power.\nAn FPGA will still be required for camera interface glue logic, but coupling to a single sensor reduces pin-count requirements. Combined with the simplified video-processing pipeline, this allows use of a much smaller FPGA. (i.e., Think iCE40 or MAX10, not Kintex.) This reduces both size and power for the entire system. Ideally, the FPGA/DSP board should fit comfortably within the footprint of the focal plane and optics assembly, either as a single PCB or wrapping around the lens using rigid-flex panels.\nTo minimize burden on the host vehicle, it should use a single upstream data port, with a daisy-chainable downstream port to add additional star-tracker modules as needed. SatCat5 is a natural fit for this requirement, forming a small Ethernet LAN to direct packets as needed. A shared serial link at 10 Mbps is likely sufficient for a handful of cameras, though 20-100 Mbps might be more future-proof for other potential products.\nThe next star tracker post will discuss major component selection.\n","permalink":"https://keppytronics.com/blog/star_intro/","title":"Star Tracker: Intro"}]