A software thing I built: GPS on a 25MHz 486-SX
71 points by JPLeRouzic a day ago | 23 comments
  • JPLeRouzic a day ago |
    The author says:

    "It used Voronoi Cells and reduced most math to 8- and 16-bit integer calculations with one or two single-precision floating-point calculations."

    I wonder if it can be used to speed up LLM inference.

    • Neywiny a day ago |
      That's what quantization and stuff is, basically. So yes. Been done for years on all neural net types not just LLMs.
      • JPLeRouzic a day ago |
        Please can you provide some links to intro level articles?
      • 4RealFreedom a day ago |
        Quantization compresses the model’s parameters and you lose precision in the process. My understanding from the article was that precision wasn't lost - 'It actually had higher resolution than Extended-precision floating point math!'. The point of quantization is to make the model smaller to fit into available ram. I think the OP is referring to computation which is a different beast.
        • Neywiny a day ago |
          You may be conflating distillation, which may be a fault of other people getting it wrong. Going from floating to fixed point doesn't change precision or size. It changes representation. For example, if all your values are between 0 and 1 or -1 and 1, you're not using the entire range of a standard IEEE float. If you instead use Q31 format, you get basically 31 instead of 23 bits of mantissa. So it's an increase in precision if and only if you can basically stretch your sub-range that you were using over a larger range of bit representations. You have to think of the total number of values. 32 bit is 4 billion. 80 bit extended precision is a lot more than that. But he didn't say I think what his fixed point bit width was. That's what matters.

          Now maybe you don't need to represent 1/2^32 in precision. Maybe you just need to know to 1/8th. That's where you can quantize to a lower precision to save space.

          But if you start with 32 bit float and quantize to 32 bit fixed, I struggle to think how that saves storage.

          • 4RealFreedom 17 hours ago |
            I wasn't conflating distillation. You are basically repeating what I said - you're describing quantization. The OP was talking about changing the computation. The article says the 8- and 16-bit integer approach actually had higher resolution than the floating-point approach. You said we already had quantization to do this but quantization isn't what the OP was describing.
  • svag a day ago |
    I believe the library mentioned in the article should be this one https://geodyssey.github.io/overview/overview.html and here https://www.lukatela.com/geodyssey/
  • SillyUsername a day ago |
    I built one, tracking fleet vehicles with a custom box, using tiled maps, on behalf of Vodafone, back in 2002. I still remember I wrote a basic trans-mercator library too!

    Of course Mercator projection may go out of fashion soon https://www.independent.co.uk/news/world/africa/world-map-eq... :)

    Hope I'm called back to update the library ;)

    • philipallstar a day ago |
      Probably not if navigation is involved:

      > This is why most online mapping platforms like Google Maps or Apple Maps rely on a variation of the Mercator projection to provide directions. Using the Equal Earth projection for navigation would not be as effective as the Mercator projection.

      > What the UN did was endorse the broader message that Equal Earth is a fairer projection that more equitably displays the true size of the Earth’s land

      You are right about this though - it's a moral fashion. Who cares about land size on a map unless you've got the priorities and advancement of a prehistoric king? People with plenty of spare time who constantly talk in an echo chamber[0], that's who.

      [0] https://un.org/en

  • guenthert a day ago |
    "real-time GPS-driven moving map display"

    Not the IMHO more interesting analog tech which lifts signals out of thermal noise.

    • JPLeRouzic a day ago |
      That looks interesting, what technology "lifts signals out of thermal noise"?
      • FrankPetrilli a day ago |
        GPS - look into Gold Codes [1] and auto-correlation. GPS arrives on your device at -128dBm, give or take, while thermal noise is -111dBm at the ~2MHz sampling bandwidth used. We use the processing gain from correlating against the ~1Mchip/s gold code to extract the lower bitrate signal, so you're pulling signals from approximately 20dB below the relevant thermal noise floor.

        [1] https://en.wikipedia.org/wiki/Gold_code

      • y04nn a day ago |
        DSSS, direct sequence spread spectrum, used for encoding GPS signal
      • peaseagee a day ago |
        Spread spectrum, it's pretty magical.
      • JPLeRouzic a day ago |
        Thanks @FrankPetrilli.
      • squantor 19 hours ago |
        I found this an interesting writeup on the technologies needed to receive GPS signals:

        http://www.aholme.co.uk/GPS/Main.htm

        The combination of RF electronics and then doing the signal processing in an FPGA for the timing critical stuff and the actual DSP with a raspberry pi, very interesting.

  • ErroneousBosh a day ago |
    One of the things I discovered a while back is that even fairly crude trig approximations don't put that much error into your position, over a small enough distance.

    To calculate things like straight-line range from where you are now to where you need to put a unit for an emergency, you're probably not working over an area of more than a couple of hundred kilometres radius and the error will be within a few dozen metres. And once you get within about half a k, you're driving towards the column of smoke anyway ;-)

  • contingencies a day ago |
    In Y2K I built a Linux on PC104 solution with GPS, bonded dual-channel mobile 9600 baud data links, and a (slow) image feed. It was kind of special to see the data coming over the mobile network in those days: this was before mobile data using basic PSTN modem tech! Very lossy and slow, as the algorithms did not account for mobile voice compression.
  • tomaskafka a day ago |
    A bit related - I tried if I can push Fable to write a Garmin map renderer that would be comparably fast (or faster) on Fenix 8 than the one they claim is possible on Fenix 9 only. I think I got very close, rendering detailed topographical vector map at over 15 fps on QEMU simulated single core simple CPU comparable to actual Fenix 8.

    https://www.reddit.com/r/Garmin/comments/1vzaz4w/we_live_in_...

  • AshamedCaptain a day ago |
    I once worked on a handheld garmin gps that used a 386 ... not sure if it ever became a product, though. It definitely had moving map... 1MB of it.
  • fegu 19 hours ago |
    Oh how I have fond memories of Dr.Dobb's journal.