• Power divider question

    Peter Walsh04/01/2020 at 03:59 0 comments

    A recent Hackaday post describes the construction of a quarter-wave impedance matching circuit. The author was asking why his system shows a resonance at around 600 MHz.

    Typing his circuit into SimSmith shows the following results.

    The first image (above) shows the SimSmith simulation of his original circuit. The green line on the Smith chart shows that a 90 degree length of his 41.56 ohm cable will indeed match the 25 ohm load to - approximately - the 50 ohm generator. The line actually lands on 69.1 ohms, which reflects the fact that he's using a constructed 41.5 ohm line and not 35 ohm line (which would make an ideal match).

    This next image shows SWR plotted as a function of frequency. His calculations indicate that the minimum SWR should be around 200 MHz, but was confused when his NanoVNA showed a minimum at 600 MHz.

    The image above shows what is actually going on. I believe he's seeing the 2nd harmonic of his calculated frequency, and SimSmith indicates that there should be a 3rd harmonic as well.

    SWR is not 1, which reflects the fact that his impedance match is not perfect - 69 ohms instead of 50 ohms - because his constructed transmission line is not the optimal value.

  • RasPi Button debounce in python

    Peter Walsh11/18/2019 at 17:22 0 comments

    I needed to debounce a RasPi button in python, and found that the software in this link has problems: sometimes the button press is ignored.

    Here's an improved version fixing the problem. It uses the GPIO hardware to initially detect the button press (rising or falling, or both) then uses a timer to detect changes in state for a user-selected debounce time.

    A full library file implementation "Button.zip" can be found in the project files section, along with a simple test program.

    DEBOUNCE_MS = 50                        # Debounce time, in ms
    UPDATE_MS   = 5                         # Update/check time, in ms
    
    class ButtonHandler(threading.Thread):
        def __init__(self, pin, func, edge='both', bouncetime=200):
            super().__init__(daemon=True)
    
            self.edge = edge
            self.func = func
            self.pin = pin
            self.bouncetime = bouncetime
            self.bounceleft = bouncetime
            self.bouncing   = 0
            self.prevpinval = GPIO.input(self.pin)
    
        def __call__(self, *args):
            if self.bouncing:
                return
    
            self.bouncing   = 1
            self.bounceleft = self.bouncetime
            self.prevpinval = GPIO.input(self.pin)
            self.timer = threading.Timer(UPDATE_MS/1000.0, self.Tick, args=args)
            self.timer.start()
    
        def Tick(self, *args):
            pinval = GPIO.input(self.pin)
    
            if self.edge == GPIO.RISING  and pinval == 0:
                self.bouncing = 0
                return
    
            if self.edge == GPIO.FALLING and pinval == 1:
                self.bouncing = 0
                return
    
            if pinval != self.prevpinval:
                self.bounceleft = self.bouncetime
    
            self.bounceleft -= UPDATE_MS
    
            if self.bounceleft <= 0:
                self.bouncing   = 0
                self.func(*args)
                self.prevpinval = pinval
                return
    
            self.prevpinval = pinval
            self.timer = threading.Timer(UPDATE_MS/1000.0, self.Tick, args=args)
            self.timer.start()
    

  • My PCB holder

    Peter Walsh03/12/2017 at 19:25 2 comments

    Reference to a discussion online.

    Here's a picture of the PCB holder I designed. It has magnets in the base, to stick to any metallic surface.

    The magnets have a surprisingly strong and stable holding force - enough that the system can hold a PCB on the metal bed of a CNC mill without bolts.

    This one has washers at the far ends. This PCB slides in from the front and stops at the washers. Reverse one side (one washer in front, one at the rear) and the PCB is locked in place.

    The side slots allow me to hold a PCB vertically or at a 45 degree angle. The elongated holes are for mounting on a mill table, and the threaded holes are for some attachments I made.

  • Fixing Alt-Tab behavior, V2.0

    Peter Walsh01/11/2017 at 02:25 0 comments

    TL;DR

    1. New version of the <alt><tab> selector is available
    2. Environment variables can define the task order
    3. Project files and wiki are on github

    A new version of Alt-Tab

    After nosing around the completely undocumented Cinnamon code for several more hours, I could find no place where the taskbar stores it's task list.

    I *did* find a function that let me safely poke around in the source files and see what information is available:

    Main.warningNotify(String1,String2);

    Later, I found a function that appears to get an environment variable:

    GLib.getenv(ORDERENV);
    And one that appears get the workspace name and index:
    Main.getWorkspaceName(global.screen.get_active_workspace().index());
    So I wrote a better version of the Alt-Tab switcher that lets the user use environment variables to set the sort order.

    You can find the new file and documentation on the GitHub project, including installation instructions and more documentation.


    Overview of the new version

    Check the GitHub project, for more/better documentation.

    The new Alt-Tab order is determined by the CLASS and TITLE of the application window.

    The CLASS identifies the application, and will be something like "Firefox" or "Nemo".

    The TITLE identifies what the application is showing, such as a specific web page (Firefox) or directory (Nemo). The TITLE is the string shown in the taskbar, and will be something like "Google - Mozilla Firefox" (for Firefox) or "Home" (for Nemo), depending on what your application is showing.

    To show all window classes and titles:

    #
    # List all window titles
    #
    wmctrl -l -x | awk '{print substr($0,index($0,$5))}'
    
    #
    # List all window classes
    #
    wmctrl -l -x | awk '{ print substr($3,1+index($3,".")) }'
    


    Setting the sort order

    Environment variables in the user's .profile file can define the sort order.

    1. In workspace n, the sort order is determined by "ALT_TAB_WORKSPACEn" if this variable exists.
    2. Otherwise, the sort order is determined by "ALT_TAB_ORDER" if this variable exists.
    3. Otherwise, the windows are sorted by title.

    The ALT_TAB_xxxx variables contain multiple CLASS:TITLE specifiers separated by semicolon.

    Workspaces are numbered from 1, not zero. The first (leftmost) workspace is "WORKSPACE1".

    The variables are part of the user's original login, so changes must be made to the user's .profile file (and not, for example, the .bashrc file). After editing, log out and log back in for changes to take effect.


    Examples

    Example1:

    export ALT_TAB_WORKSPACE1="Firefox;Nemo;Gnome-terminal"
    export ALT_TAB_WORKSPACE2="Gnome-terminal:Edit;Gnome-terminal:Work;VirtualBox;Firefox;Nemo"

    In WORKSPACE1 the alt-tab listing will have firefox leftmost (in first position), Nemo in 2nd position, the terminal in third position. Other windows will be to the right of the terminal.

    In WORKSPACE2 the alt-tab listing will have both terminals leftmost, but the one titled "Edit" will come before (to the left) of the one titled "Work", in 2nd position. VirtualBox, Firefox, and Nemo will follow, then any unspecified windows.

    Other workspaces will be sorted by title (the default).


    Example2:

    export ALT_TAB_ORDER="Firefox;Nemo;Gnome-terminal"
    export ALT_TAB_WORKSPACE2="Gnome-terminal:Edit;Gnome-terminal:Work;VirtualBox;Firefox;Nemo"

    WORKSPACE2 Alt-Tab will be as described above.

    All other workspaces will show Firefox->Nemo->Gnome.


    Example3:

    #
    # No preference in window order
    #
    #export ALT_TAB_ORDER="Firefox;Nemo;Gnome-terminal"
    

    Alt-tab will sort by title, the default.


    Named Workspaces

    If you have named your workspace, use "ALT_TAB_" with the new workspace name.

    Example4:

    #
    # Workspace named "PERSONAL"
    #
    export ALT_TAB_PERSONAL="Thunderbird;Firefox;Nemo"
    

    The renamed workspace "PERSONAL" will show in the order Thunderbird -> Firefox -> Nemo

    All other workspaces will sort by title, the default.

  • Fixing Alt-Tab behavior

    Peter Walsh12/26/2016 at 19:49 1 comment

    I'm on a campaign to remove minor annoyances in my life, and the alt-tab behavior in Cinnamon finally annoyed me enough that I had to change it.

    The new version presents the task list in a fixed and predictable order every time alt-tab is activated, which allows me to use muscle memory to quickly switch between windows.

    Update1: A diff listing below shows the changes more clearly.

    Update2: Firefox and Chrome titles include the web page title; in other words, their window_title(), hence their position in the list, will change depending on which webpage is accessed.

    The solution might be to sort on "Mozilla" or "Chrome" if the task name contains "Mozilla" or "Chrome". Perhaps if the title contains a dash, sort on the substring after the dash character. I'll look into that later if it becomes a problem or if enough people request it.


    The Problem Statement

    On linux/Cinnamon (and windows), pressing <alt><tab> pops up a list of active applications, allowing the user to navigate and select a window to switch to. When a different window is selected, the current window is pushed down, and the new window comes forward.

    The problem is that alt-tab sorts the windows in least-recently-used order; meaning, the window you are in is the 1st position, the one you were in last is in 2nd position, and so on.

    This works for switching between two - and only two - windows, but if you need three or more it quickly becomes a permutation engine. Selecting the 4th window puts the 1st window in 2nd place, the 2nd window in 3rd place, and so on.

    For example, if you simultaneously use an editor for source, a command window to build, and a third window for test (seeing the results), you cannot quickly switch between windows because the ordering is always different. You have to stop, look at the list, recognize the icons, and then tell your fingers how many times to tap the <tab> key.

    Add one or two more apps (a file explorer say, or a system monitor) and it rapidly becomes an exercise in fumbling and redoing while paying attention: your fingers *want* to learn a fixed action to switch to the editor, but half the time they go somewhere else and you have to stop, look, and recover.

    It's annoying as hell.


    Initial Attempts

    My go-to solution for these sorts of problems is to go out on the net and see if someone else has solved it, then download their solution. Usually with an "apt-get install their-solution" command.

    Apparently no one has done this for Alt-Tab. So far as I can tell, there's no add-on or applet that will change the behavior.

    However, in looking around the net I accidentally found a reference to this file:

    /usr/share/cinnamon/js/ui/appSwitcher/appSwitcher.js
    

    Could editing this file change the alt-tab behavior?


    Step 1: Is this the right file?

    Linux comes with a long list of default annoyances, and the first step in fixing any of them is to find the right file to change. This can take anywhere from 4 hours to several days, depending on on the specific annoyance you want to change.

    So when I found the file reference above, I knew that there was a fair chance I could address the issue without spending a lot of time finding the right file.

    Maybe.

    Editing Cinnamon files is roughly akin to walking a tightrope over a canyon with no net: it's trivial to completely bork your system in such a way that a complete system reinstall is the easiest fix.

    Knowing this, I felt it was *likely* that messing up alt-tab *probably* wouldn't completely bork my system, since I could reboot and put things back without activating the alt-tab function.

    I've been wrong about this before. To give you an idea of how easy this is, I typo'ed the filename of the screen saver executable, and Cinnamon went into an infinite error-popup-reload cycle that was almost impossible to get out of. You would *think* that missing a screen saver would not be a critical/must reboot error, but it was.

    Looking through the directory, I noticed the file "classicSwitcher.js" has the following few lines...

    Read more »

  • Clothespin Switches

    Peter Walsh12/15/2016 at 21:26 0 comments

    Some images for a response on the blog.

    You can make an improvised switch by pressing two thumb tacks into the jaws of a clothespin, and soldering wires to the nails that stick through.

    Then put something between the jaws to break the contact.

    For example, grab the plastic tab that holds a loaf of bread shut and tie some fishing line to that. Place the plastic tab between the jaws, run the line across a doorway or path, and anchor the end to the wall somehow.

    When a person enters the room/crosses the path, their leg snags the fishing line and pulls the tab out from the jaws of the clothespin, completing the circuit.

    (Note: The particular buzzer used is really, *really* loud!)

    (From the article, you can put an aspirin between the jaws to detect moisture.)

    The version below includes a battery and a transistor socket. Stick the wires of a flashbulb into the socket and use the plastic tab as described above to make a flash-bulb warning of intruders.

    Also of note: It's hard to see from the photo, there are 2 thumb tacks sticking out from the base of the battery. Take the whole unit and press it into the side of a tree or wooden molding and run the trip wire across the room to another thumbtack.

    Takes about a minute to install 1 intruder sensor.

    I probably shouldn't mention this, but mount a 35mm film canister on the clothespin, put the flashbulb *inside* the canister, and fill the canister with gunpowder.

    This makes a very satisfying flash *and* bang for unwanted intruders!

    It's also reasonably safe, assuming you use a plastic film canister and not a metal one.

    I couldn't immediately find one of those or I would have posted an image.

  • An Industrial Robotic Arm for Hobbyists

    Peter Walsh12/05/2016 at 01:44 0 comments

    [A Hackaday article submitted for the "we're hiring" article.]

    [Third attempt. I can't seem to find a good enough article to write about for Hackaday, so maybe I'll just compose one of my own. A "good enough" article needs a video, is interesting, and not already have a HAD article covering it.]

    [Oh, wait! Here's one...]

    by Peter Walsh

    One of the best things about the Hackaday prize is that it presents all manner of great projects to the world to build, modify, and learn from. One of these is the Thor 3-d printed robotic arm.

    Thor is not your typical hobbyist or robotics club build, it's pretty much a scaled-down industrial robotic arm in a desktop configuration. The yaw­-roll­-roll­-yaw­-roll­-yaw configuration is the same as found in many industrial robots on the market.

    The arm has six degrees of freedom using seven stepper motors, some of which are gear-reduced for greater torque. The design hides the internal mechanism: all the pulleys, belts and wiring are enclosed, making the whole project kid safe.

    Steppers are controlled by an Arduino Mega using a specially-designed 7-motor driver shield and pololu motor drivers. The system could probably also be driven by a couple of RAMPS boards, and the project logs talk about using a smoothie board to control 5 of the seven motors.

    Thor is 3-d printed plus hardware, and the entire kit looks like it would be perfect for learning about industrial robotics, solving a Rubik's cube, or perhaps stirring your tea.

    We've seen robotic arm projects on Hackaday before, including one made from cardboard.

    Check out the video of Thor in action after the break.

    Posted in Arduino Hacks, robots hacks

    Tagged ,

  • Transformer from Washing Machine

    Peter Walsh12/04/2016 at 22:54 0 comments

    [A Hackaday article submitted for the "we're hiring" article.]

    FAIL!

    After writing the article, it doesn't meet the "at least 150 words" requirement, and I don't see a good way to add more text. I could change the scope from this specific project to transformers in general, I suppose.

    Finding a good project to report on is HARD!

    by Peter Walsh

    In the zombie apocalypse, if you need a transformer and all you have is an old washing machine, we've got you covered.

    [electricretrotech] First removed the induction motor from an old washing machine and unwound the coils, resulting in a bare iron core and several heaps of wire. He then rewound the core into a transformer configuration using some of the wire removed in the first step.

    The result is a rather useable transformer that looks like it could be used as an ad-hoc spot welder. Assuming the windings don't exceed the maximum flux density of the iron core, the resulting transformer would even be reasonably efficient.

    If you want to try winding your own transformers, check out Practical Transformer Winding for some step-by-step instructions.

    Continue reading


  • Ground-based delivery drone probably won't get stolen

    Peter Walsh12/04/2016 at 22:04 0 comments

    [A Hackaday article submitted for the "we're hiring" article.]

    FAIL!

    After some composition work, it looked too much like a press release and didn't fit in with the "look and feel" of Hackaday, so I scrapped it in search of a better project. (Note: Text below is unfinished.)

    by Peter Walsh

    Drone delivery is the next big thing in robotics, especially for "last mile" delivery. Amazon, for example, is developing an airborne drone delivery system to deliver goods directly from a nearby distribution center or truck.

    Starship Robots, a ground-based drone delivery system that can carry two shopping bags worth of goods, has completed preliminary testing in a handful of cities in Europe, and will begin testing in American cities sometime this fall.

    Ground-based has a lot of advantages over drone-based: it's safer for the public, can carry heavier and bulkier items, and requires less energy than airborne delivery. The robots are semi-autonomous and can can make simple decisions on their own to avoid collisions and navigate around obstacles (such as pets). The device can also call for a human remote operator when it encounters situations it can't handle.

    The...

    Starchip robots have traveled close to 5,000 miles and encountered over 400,000 people without a single accident. It claimed that during testing, about two-thirds of people ignored the bots entirely, while the rest reacted to them mostly favorably, often by snapping photos. (Note: Clipped from other article, used as "notes" to inform my own writing.)

    Check out the video below the break to see the drones in action.

    Continue reading

  • Optical flow sensor from an LED mouse

    Peter Walsh11/22/2016 at 02:15 4 comments

    (A response to a question on the blog.)

    Here's an example of working with an optical flow sensor.

    Take an LED mouse and clip out the DIP micro using a pair of side cutters, then install headers into the footprint. You can then attach jumpers to PWR, GND, and the two SPI lines as needed.

    And here's my homemade dev kit. The mouse board is under the "ferris wheel", which was cut from a laser. Turn the wheel by hand and watch the measurements flow by on the serial port.

    (Using an arduino program to read the flow sensor.)

    I'd give out the arduino code, but it's a bare-metal program (ie - not a sketch). Not for the faint of heart.

    If there's a ton of interest I'll put the code up somewhere.