ISP programming of the (tr)uSDX (trusdx) showed that filtering on the MOSI pin in that kit distorted the MOSI signal significantly and suggested a workaround (reducing SCK rate) for reliable programming.
Some correspondence prompts a little more information on the nature of the ATmega328P ISCP signals.
The line protocol used is actually SPI, quite a common protocol.
ISP uses SPI MODE 0 (CPOL=0, CPHA=0), shift out on the falling edge of SCK, and capture input on the rising edge.
Let’s look at a three channel capture of SCK, MOSI and MISO of a AVRDUDE / USBasp driving an Arduino Nano.
I noted some online discussions where some people had troubles using an ISP programmer to program the MCU.
I do not have a (tr)uSDX (trusdx), but inspection of the schematic does hint what those users are doing wrong.
Loading the SCK, MOSI and MISO lines risks problems with operation of the SPI protocol used, but the effect depends to some extent on the driver, length and type of interconnecting cable etc.
Here are some measurements of a USBasp driving an Arduino board with 5V Atmega328P 16MHz chip using about 200mm of ribbon cable… AND the MOSI line is loaded with a 0.01µF capacitor (as in the (tr)uSDX schematic).
Several of my projects use Bosch BME280 sensor chips for measuring temperature, pressure and humidity.
Some correspondents have expressed problems using BME280 modules that they bought online, and it is usually because they have been cheated by online sellers misrepresenting BMP280 as BME280.
My projects that include code to initialise and read BME280 humidity will fail on a BMP280… check to see if the humidity results returned look sane. A driver may read the ChipID and fault on the ID returned by a BMP280.
The Bosch chips are usually visually different, and most clones likewise.
I have used PERL to script NEC runs, and then to read the huge volume of output to produce simpler summary tables. This has provided facility to run a very large number of models with some variation in one or more model parameters. One of the early published web articles was Feeding a G5RV published in 2005, but I had been using PERL for that purpose for quite some time before that, and in my ‘day job’ since early 1990s. Ham projects led to development of some application specific libraries to model transmission lines and ATUs.
Like PERL, Python had its origins in the late 1980s, but it has really only come of age in recent years with the release of v3. Python appears running on all sorts of things from microcontrollers up, and is probably the most popular scripting language today. Continue reading PERL vs Python pre / post processing NEC
Recent versions of Windows 10 have made changes to some audio input processing.
Above is a screenshot of a Microphone Properties window, and attention is drawn to the section highlighted in pink which may appear in some devices.
The Signal Enhancements would appear to introduce certain non-linear behaviour.
I preface this with saying the ‘enhancements’ are probably hardware dependent (ie the chipset used and driver capability) but may also include Windows core, and this report applies to my specific configuration but hints issues that may be systemic.
That said, I performed a simple test switching an audio sine generator between two close frequencies and observed the level vs time in SpectrumLab.
I wrote an application that presents maps on a webpage using Leaflet and OpenStreetMaps, and some readers commented that the text was hard to read on their devices.
It turns out that this issue seems present on devices with high resolution small screen (ie high pixels/mm or small pixel size).
The reports raise the question of whether it is the compatibility of the device and the user’s Visual Accuity (VA).
VA is often assessed on the familiar Snellen chart which has characters of a 5×5 grid and normal vision is indicated by reading characters that subtend 5 minutes of arc (MOA), or 1MOA for each ‘pixel’ (px).