Typo - part 9 - "hz"

[greenonline]

A minor point but the SI unit for frequency is Hz not hz. Also, there should be a [non-breaking] space ( ) before SI units (see Don't forget the space!).

So

The Raspberry Pi 4’s clock oscillator frequency is 54Mhz

should be

The Raspberry Pi 4’s clock oscillator frequency is 54 MHz

The Raspberry Pi 4’s clock oscillator frequency is 54 MHz

and

Technically speaking, it’s 8-bit, unsigned PCM data at 44.1Khz

should be

Technically speaking, it’s 8-bit, unsigned PCM data at 44.1 KHz

Technically speaking, it’s 8-bit, unsigned PCM data at 44.1 KHz

There are also four other instances in this paragraph:

These pulses/bursts do need to be highly accurate for this trick to work, and so we need a reliable clock source. Just like your kitchen clock ticks every second, so the oscillator on the Raspberry Pi 4 has a regular ‘tick’ - in this case, 54,000,000 times per second (54Mhz)! Our audio sample is at 44.1Khz though, so we need to ‘slow it down’. We do this by first stopping the clock, then setting a clock divisor, setting the PWM range, and enabling the clock again. In my code, I use 2 as the clock divisor (so we’re down to 27Mhz) and set the range to 612 (0x264). Essentially, this means that our PWM module will move to a new sample every 27,000,000/612 times per second - roughly equivalent to 44.1Khz, which just happens to be the sample rate of the included audio sample audio.bin (I’ve included audio.wav so you can listen normally on your laptop too!).

[paulwratt]

@greenonline you should look up "perdantic"

Its consistant across the documents and not untrue, so unless you submit a PR this probably wont change.

Also note, to provide non-ASCII format patch (HTML in this case) for a ASCII format document (Markdown) is a no-no. (however a plain space would be acceptable)

Glad to see you made it all the way through the tutorial, and presume you are like me, waiting "impatiently" for the next part ..

[babbleberry]

I respect the correctness of your comment @greenonline, but I think the time taken to change is disproportionate to the value of doing so.

I have been described as a "pedant" in my time, regularly correcting others on their incorrect grammar, but I was helpfully once advised by a linguist (a graduate of both Oxford and Cambridge, now working for GCHQ) that the purpose of language is to communicate, and if the message is received and correctly understood then the form is irrelevant. I think people will know what I meant in this case.

Also, @paulwratt, I'd love to hear where you'd like to see me take this next? Any particular points of interest? We had a new addition to the family and so I've been AFK more than I'd like recently! But I am committed to continuing my work here... Glad it's useful!

[greenonline]

@isometimes - I would like to see an additional part on getting USB working. You mentioned in part 7, that it was a lot of work, or rather more complex than just getting Bluettoh up and running, so maybe it would be more than just one part, or maybe it would be too much scoping the scope of your tutorial.

Anyway, I'm on the penultimate part (SPI-Ethernet) now and have really enjoyed the read. Many thanks.

---

I am sorry if some of the bugs raised have seemed "perdantic"... however, it is merely because the tutorial was so highly polished, that I felt that the few bloopers that I did find should be raised as issues, because they took the edge off that shine (but only ever so slightly, though!).

I often find that if I'm using a product, that is new to me (be that software/hardware or even a book), and I find a bug somewhere, then flags are raised to be on the look out for more. Also, inner alarm bells go off warning that the product may have other, (possibly) more serious, flaws. Basically, if I find one issue, then my coinfidence in that product immediately starts to drop - and I'm sure that I'm not the only person to feel this way. Hence why, if I can, I will report such an issue in the hope of having that niggle dealt with.

I understand that for day to day spoken comms typos/grammar aren't a major issue and, as a polygot myself, I find constant grammar correction irritating during conversation. However, for the written word, especially in a technical document, accuracy is king.

[babbleberry]

Ok, ok, you convinced me! I've corrected the SI units, but without the non-breaking space. I agree that HTML should not form part of a plain text document. Hope that's a good compromise 😄