snops

Almost definitely a cost decision.

USB-C alternate mode for Displayport currently (and probably always will) requires an external port controller to negotiate the alternate mode with the other end of the cable over the configuration channel (CC) pins, and possibly a high speed mux[2] if you want USB-3.0 over the same pins as well. Simpler applications like analogue headphones or USB-C to Type A adaptor cables just use specific resistor values instead, a wise decision by the standards body IMO.

Of course, if you have that built into the SoC[3], the cost of that is reduced a lot once the IP license is covered, and makes sense for a several hundred dollar phone/laptop, though there are some extra electical requirements that come with USB-C such as tolerating 20V (in case someone plugs in a laptop adaptor that has not discharged down to 5V in time) that is hard to implement in the same silicon as the rest of the SoC, and so some external logic is almost always needed.

In addition, an actual USB-C connector is relatively expensive due to the high pin count, fine tolerances and the shape requiring use of deep-draw or metal-injection-moulding method.

Micro HDMI has much simpler interface requirements, sometimes some discrete transistors for the hot plug detect signal and a low speed level shifter for the DDC bus. The connector can be cheaper to manufacture as well as the shell can be stamped out like a Micro USB connector.

There are licensing costs[4] for HDMI, while DisplayPort is royalty free, but I reckon Broadcom can negotiate that down considerably from the published figures, and I can't see USB-C being cheaper than the listed 5 cents per device charge.

[1] https://www.cypress.com/products/ez-pd-ccg1-type-c-port-cont... [2] http://www.ti.com/product/HD3SS3220 [3] https://ip.cadence.com/ipportfolio/ip-portfolio-overview/int... [4] https://en.wikipedia.org/wiki/HDMI#HDMI_Fee_Structure

Huge difference in power level, your link is to an RF jammer which would not work with drones using inertial or optical navigation, which is very practical for the short distance a drone needs to travel in sight of the target.

The original article shows what looks like a much more powerful system, that would induce high enough voltages/currents in the drone electronics to cause permanent damage, the same as if you put one in a microwave oven, they are really not comparable.

An interesting question would be how fast the original dish can turn, a slow traversal would very much limit its effectiveness.

When the LimeSDR Kickstarter was underway, one of the selling points was launching an app store based on Snaps on Ubuntu, I think this is the current version of that [1], which seems a bit empty to me.

GNURadio does also have a store directly for it called PyBOMBS [2] as well, though it is unfortunately not included by default, and it has been a few years since I checked it so I don't know how much it has.

Gnuradio is a bit overcomplicated at this point also, using both Qt and GTK, and a long list of other dependencies.

Luaradio[2] is quite nice as an alternative, and is much easier to embed into an end application as Lua itself is very good at that kind of thing.

[1] https://limenet.snapcraft.io/ [2] hhttps://github.com/gnuradio/pybombs [3] http://luaradio.io/

Ah, by "this" I meant the articles 60Hz timer, not the proper date/time peripheral I imagined the article to be from the title.

For a 60Hz timer, just being able to have a delay without needing to count all the instructions in between when programming.

Not what I was expecting, normally I would expect a real time clock to keep running when the system was turned off, so you would be able to have accurate current date/time.

I'm also very surprised to see that apparently the Apple II didn't have something like this built in already, were all delays implemented as busy loops?

The SI units are supposed to be used to define all other units.

The mole is just a unitless number which isn't used for many definitions, while the bit (or preferably, Shannon) has a fundamental use in information theory and the wider field of physics.

The mole is a human specific number, the bit is a property of the universe. Information is a physical quantity, just like mass or length, and deserves to have a unit in the SI system. You could use other bases, like the nebit (natural log) or Hart (base 10), but bit is most elegant as it uses the smallest integer base possible, 2.

It's surprising they have both the "Titan M" security chip and a ST33J2M0 security microcontroller.

You would think just one would do for key storage. Skimming the hardware backed keystore overview, it only mentions one secure coprocessor: https://source.android.com/security/keystore

The automatic handling of the shared memory section with the linker script is really nice, I've previously manually hardcoded this when doing C. An "include" directive can ensure the right address is used, but enforcing/verifying the layout too is nicer.

On a lot of microcontrollers with multiple cores, there is a specific semaphore peripheral, that can be used instead of shared memory. STM32 has HSEM for instance. It would be interesting to see if this could be used by Rust in future, if this offers any benefits, and if this could be done in a somewhat transparent matter.

After some digging, it appears the particular tech they are using is Locata[1], which uses a time of flight based positioning system.

To deal with the terrible multipath problems in a site full of metal boxes, a phased array approach is used to so the receiver antenna is directional and electronically steerable. Locata have a clever way of doing this called vRay [2]. This uses time-slicing rather than many simultaneous receivers to cut costs, and you can see this ball of smaller antennas on top in several shots.

In contrast, the ultrawideband (UWB) tech you have linked uses the frequency specific nature of multipath to average out the error, but as UWB is over a range of frequencies used for other purposes, it is very limited in legal TX power, and so I suspect it would have range issues in this application.

[1] http://www.locata.com/technology/locata-tech-explained/locat... [2] http://www.locata.com/article/vray-antenna/

My favourite trick with designated initialisers is using them with array indices and enums, e.g.

  enum color {RED, GREEN, BLUE};
  char *color_name[] = {
    [RED] = "Red",
    [GREEN] = "Green",
    [BLUE] = "Blue"
  };

  printf("%s",color_name[RED]);

This means you don't have to ensure ordering is the same between the enum and the array, which can be a pain for more complex tables. It's a shame C++ doesn't support this, more details: https://eli.thegreenplace.net/2011/02/15/array-initializatio...

I think you are being quite harsh, net labels are fine for embedded/digital stuff, which generally consists of quite separate functional blocks with few, easily reasoned signals between them (e.g. power + I2C). A lot of Sparkfun's products fall into this category.

The Arduino Uno by contrast uses routing too much in my opinion, and is quite hideous: https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic...

If you look at say laptop or SoC development board schematics, they are full of net names, and they certainly aren't using physical pin positions. In fact quite the opposite, one physical device is often split into multiple schematic symbols (e.g. supply rails are one symbol). For the overall system, they use a block diagram or hierarchical schematic. Here is the BeagleBone schematic, which I think makes good use of net labels, e.g. the BAT connection on page 2: https://beagleboard.org/static/beaglebone/BEAGLEBONE_SCHEM_A...

I will agree with you on net names for analog systems, such as audio amplifiers or complex power supplies. There, net names can quite often be misused, as you need to keep more connections in your head when trying to understand a circuit, and it is much harder to remember all the net names than see a direct connection.

For a interpreter targeted at small/embedded devices, it would be interesting to see the ROM/RAM usage.

Microchip sell a commercial version of a similar technology called "Bodycom", which has a similar low data rate and deliberately short range away from the human body.

It's quite old now though, so it's possible modern BLE systems are more power efficient.

https://www.microchip.com/design-centers/embedded-security/t...

Given how the SOM version connects over PCI-E, maybe it is a USB3.0 to PCI-E bridge?

A benchmark test against Nvidia Jetson would be very interesting, especially if it compared power consumption as well.

Agreed, and there are very few accelerometers/gyros available in packages that don't require ENIG for reliability as the market is driven by phone usage, it would almost definitely cost more to get an (obscure/old) accel than just use ENIG.

I agree with the rest of OPs points though, all the seperate LED boards are a bit excessive.

A quite high quality device by the looks of it, no wonder it is $90!

Interesting to see that each LED is individually dimmable when the device is not a display (the 3 LED drivers are 16 channels each, and there are 48 LEDs total). Looking at the animations on the article, you should only need 8 channels or so to get the top to bottom effect, using a higher voltage boost to get the LEDs as series strings. It's a fairly expensive LED driver to have that many of them, but I guess designing it that way adds flexibility in future. (A "flickering candle" effect maybe?).

The use of the discrete Nordic IC rather than a module definitely suggests a higher volume product to justify the cert costs, especially as the device is not pushed for space.

Finally, the power management side is also quite premium, with a high current switching battery charger. Looking at another review[1], it appears to come with a mains adaptor permenantly wired to the base, rather than use Micro USB. As the pogo pins are quite small, the mains adaptor might provide a higher voltage e.g. 12V to reduce the current through the pins, and so a more expensive switching charger is used to step this voltage down for the battery. The battery wiring appears to be doubled up as well for a higher charge current by using more connector pins, so it can probably charge quickly in 2.5 hours or so (0.5C). Surprised they didn't just use a larger connector and wiring, again this isn't a small product.

[1] https://www.macrumors.com/review/casper-glow-light/

The main change would be to the power supply, as the esp8266 has a far higher (~300mA) peak current than the ATTiny814 used (~3mA). Currently, an LDO provides 3.3V from the 24-35V motor supply. This would need to be changed to a buck DC/DC regulator, as a larger LDO at this voltage would need too big a heatsink for the case.

A really good article! The telecoms world is fascinating, it's a whole separate parallel stack that doesn't get talked about anything like as much as the web world.

One section caught my eye, and I wanted to add some detail:

>In order to efficiently send and receive signals, antennas should be no smaller than half the size of the radio waves they’re dealing with. If cell waves are 6 to 14 inches, their antennas need to be 3-7 inches. Now stop and think about the average height of a mobile phone, and why they never seem to get much smaller.

A common neat trick is to take advantage of the fact that this is only true in air, and the wavelength depends on the material around the antenna. Some modern antennas (especially common in GPS and Bluetooth) are built as a metal foil around a ceramic element, which has a much shorter wavelength and allows them to be shrunk[1].

You can also "fold" the antenna a bit, and hence get away with a quarter wavelength in return for reduced performance in other areas. A common example in phones is the Inverted F antenna [2].

Finally, a large "invisible" component of many antennas is the size of the ground plane attached. Shrinking this can affect antenna performance a lot. Generally, this is an internal copper layer of the PCB that is used by other components too, but it's important to realise its an important part of the RF performance. Therefore, you can't judge how good an antenna is from the visible size of it alone, the form of the whole device matters.

[1] https://electronics.stackexchange.com/a/245245

[2] http://www.antenna-theory.com/antennas/aperture/ifa.php

NaCL: https://nacl.cr.yp.to

Is a crypto library designed to do exactly this, have a sensible API that does not expose any internal details for misuse, and generally gives you only one way to do things based on best practice algorithms.

It's got some big names behind it, and has probably quite mature since it's been going for several years.

There is also a popular fork, libsodium: https://libsodium.gitbook.io/doc/, which I think is more portable.

A good in-between option is a parser generator like Ragel ,http://www.colm.net/open-source/ragel/

This takes in the definition of a regular language as a set of regular expressions, and generates C code for finite state machine to parse the language. You can visualise the state machine in Graphviz to manually verify all paths, making it much easier to spot hidden corner cases, while being a lot quicker to code than a big pile of if statements.

Since the USB-C port often supports bidirectional power, it may not actually make it that much larger, if at all, as the battery charger IC can often operate in "reverse buck" mode to turn the battery voltage into 5V, which when using synchronous rectification (almost mandatory for efficiency now) means it has all the parts for forward boost, and just needs a slightly cleverer control IC. This is like how many modern power banks can use the same inductor for buck (5V->3.7V) charging and boost (3.7->5V) discharging.

Check this app note from Intersil/Renesas: https://www.renesas.com/eu/en/doc/whitepapers/power/usb-c-bu...

(of course, it may be slightly less efficient in boost charging, but since the 5V usb source has limited power, this may not be a concern in terms of component thermal limits etc).

I think orbiting around L2 would ensure the satellite was at a higher angle in the lunar sky for most of the time, and hence the lander can be in contact for longer, as low angles may be blocked by boulders or crater walls etc. The radio to the satellite would normally use high frequencies so you can have a focused beam for power saving, so it needs to be line of sight. You could transmit faster, but this would take more power.

In addition, there is a little rover[1]. NASA rovers since Pathfinder have had some automated driving, I imagine the Chinese can easily do the same, but manually steering is still nice and hence the rover is more useful if you can be in "live" contact with it for longer.

[1] https://en.wikipedia.org/wiki/Chang%27e_4#Yutu-2_rover

For another option, see OpenHTF from google, though this targets quite complex devices: https://github.com/google/openhtf

PCI-E is a good form factor for embedding an FPGA in a laptop, (especially as the spare but is still very difficult to debug issues with if you need high performance, you would not expect to actually get the full 2.5GT/S without some very hard work in the rest of your design.

See the fun issues the XTRX project had getting good IO performance with an FPGA based SDR in the same form factor (PDF): https://xtrxsdr.files.wordpress.com/2017/01/xtrx-chasing-pci...

A larger problem with this board, it doesn't have any onboard JTAG programmer, so if you put it into your laptop you will have to take it out every time to reprogram it! This is a shame, as Mini PCI-E mandates a USB 2.0 interface as well which would be useful for a programmer, while M.2 apparently only has USB optionally, see https://en.wikipedia.org/wiki/M.2#Form_factors_and_keying

Actual link to the module, with tech specs: https://developer.nvidia.com/embedded/buy/jetson-agx-xavier

A good set of links to resources: https://elinux.org/Jetson_AGX_Xavier

Overall, looks incredibly powerful for the form factor and power usage, with a ton of high speed camera, display, and PCIE interfaces.

I don't see any mention of production lifetime gaurantees, presumably that's a "please ask". Other SoM manufacturers promise a few years (up to 10), so you don't have to worry about redesigning your product every year. For the Jetson module, it's designed to be fairly tightly integrated and hence an swap out would not be trivial, e.g. you need to design a heatsink system for it yourself so you can choose a fan or heat pipe it to the enclosure walls.

Conformal coating is used, which is a thin layer of polymer sprayed as a film over the finished and soldered PCB.

As modern components are normally much smaller and sit fairly flush with the PCB, there are less nooks and crannies, and so the coating manages to fill them all or bridge them over quite well. It's still not a step used in most PCBs, there are downsides like requiring connectors and switches to be masked off with tape, and so it is reserved for more extreme applications than consumer electronics. Think electric gate control boxes, or marine electronics.

It would probably have existed in some form at the time of the OPs radio, but spraying the PCBs in it wouldn't have saved all the connectors, switches pots and other front panel controls from moisture, and so a more general method was needed.

Finally, a more extreme step is to "pot" the entire PCB by putting it in a sealed container and filling the container with a "potting compound", a liquid resin that sets solid or to a rubbery finish. This makes replacing or repairing the PCB very difficult, requires a lot of thought as to connectors, and it doesn't work well for high power electronics as the potting compound traps heat. It allows you to fully submerse a PCB in water forever, stops sparks if your PCB is working around explosive gases/powders, and is sometimes used as a "security" method in hardware security modules or "secure" USB keys.

For security, potting only really works if tiny wires are embedded in it, which on breaking wipe the encryption keys. Scraping off potting compound can otherwise be done by anyone if they are willing to spend a long time.

I remember from the excellent book "Expert C Programming: Deep C Secrets", that the Sun C compiler also took a similar approach to using malloc, so it isn't unheard of for compilers specifically.

I disagree with your characterisation of this as bad practice and "not facing it", it is an informed decision rather than ignorance, and brings considerable benefits. With a C complier, some reasonable estimates can be made of the input data length/complexity and hence allocation sizes, and having poor performance if someone tries to feed in a million line file is perfectly acceptable, especially in a complier designed to be simple like the OP.

I think recognising the special set of circumstances that justify making an unusual tradeoff that wouldn't normally be acceptable is actually a mark of maturity as a programmer, not a bad attitude. The phrase "Don't let perfect be the enemy of good" comes to mind.

Finally, why would it bring burden to the OS if you invoke this multiple times sequentially? malloc/free is implemented in the C library, not in the kernel, it's a mechanism for sharing bigger chunks fetched/given-back from/to the kernel with sbrk(). The kernel would just reclaim the pages on program exit, as it would have to anyway, as it cannot rely on programs being well behaved enough to call free() (which rarely would give the memory back to the kernel immediately anyway). Since the kernel uses virtual memory, its not actually moving the contents about, just manipulating page tables, so it should be quite fast, and zeroing memory is not as time consuming as you think due to Zero Fill On Demand (ZFOD), and hence the kernel does about the same amount of work regardless of if the program called free() or not.

Sure it's using more peak memory than it could be, but I reckon compared to say, a web browser, it's still a very small fraction of the total.

For a related (but less complicated) project, see Mozilla's RNNoise project, which uses neural networks to better tune classical signal processing algorithms to reduce noise in recorded speech: https://people.xiph.org/~jm/demo/rnnoise/

They are actually from numpy, scipy just re-exports them, so they work with numpy arrays which the built in maths would not. I guess the author writes a lot of scientific code, so is in the habit of using them.

Numpy arrays are much faster than python lists etc for maths and matrix operations, (e.g. multiply this 1000 element vector by 2), which are common in scientific and engineering code.

https://docs.scipy.org/doc/numpy-1.15.1/reference/generated/...