Many makers start by building mock-ups from cardboard, but [Alex-08] has managed to build an R/C plane that actually flies, out of cardboard.

If you’ve been thinking of building an R/C plane from scratch yourself, this guide is an excellent place to start. [Alex-08] goes through excruciating detail on how he designed and constructed this marvel. The section on building the wings is particularly detailed since that’s the most crucial element in making sure this plane can get airborne.

Some off-the-shelf R/C parts and 3D printed components round out the parts list to complement the large cardboard box used for most of the structural components. The build instructions even go through some tips on getting that vintage aircraft feel and how to adjust everything for a smooth flight.

Need a wind tunnel instead? You can build that out of cardboard too. If paper airplanes are more your thing, how about launching them from space? And if you’re just trying to get a head start on Halloween, why not laser cut an airplane costume from cardboard?

[Aaron Lager]’s Pi-O-Scope-Pong project takes a minimal approach to Pong by drawing on an oscilloscope to generate crisp paddles and ball. A Raspberry Pi takes care of the grunt work of signal generation, and even uses the two joysticks of an Xbox controller (connected to the Pi over Bluetooth) for inputs.

Originally, [Aaron] attempted to generate the necessary signals directly from the Pi’s PWM outputs by doing a little bit of RC filtering on the outputs, but was repulsed by the smeary results. The solution? An old but perfectly serviceable 8-bit MAX506 DAC now handles crisping up the visuals with high-quality analog outputs. Code is available on the project’s GitHub repository.

There isn’t any score-keeping or sound, but one thing that it has over the original Pong is a round ball. The ball in the original Pong game was square, but mainly because cost was a concern during design and generating a round ball would have ballooned the part count.

In many ways, Pong itself is a great inspiration for the Tiny Games Challenge, because the simplicity of its gameplay was likely a big part of its success.

youtube.com/embed/WMYsr0fLufo?…

Pity the video team at a large hacker camp, because they have a huge pile of interesting talks in the can but only the limited resources of volunteers to put them online. Thus we often see talks appearing from past camps, and such it is with one from Electromagnetic Field 2022. It’s from [Sarah Angliss], and as its subject it takes the extraordinary work of [Muriel Howorth], a mid-20th-century British proponent of irradiated seeds as a means to solve world hunger.

Today we are used to genetic modification in the context of plants, and while it remains a controversial subject, the science behind it is well known. In the period following the Second World War there was a different approach to improving crops by modifying their genetics: irradiating seeds in a scattergun approach to genetic modification, in the hope that among thousands of duds there might be a mutant with special properties.

To this came Muriel Howorth, at first charged with telling the story of atomic research for the general public. She took irradiated seeds from Oak Ridge in the USA, and turned them into a citizen science program, with an atomic gardening society who would test these seeds and hopefully, find the supercrops within. It’s a wonderfully eccentric tale that might otherwise be the plot of a Wallace and Gromit movie, and but for a few interested historians of popular science it might otherwise have slipped into obscurity. We’re sorry we didn’t catch this one live back when we attended the event.

media.ccc.de/v/emf2022-353-the…

In the previous article we looked at designing a lock-free ring buffer (LFRB) in Ada, contrasting and comparing it with the C++-based version which it is based on, and highlighting the Ada way of doing things. In this article we’ll cover implementing the LFRB, including the data request task that the LFRB will be using to fill the buffer with. Accompanying the LFRB is a test driver, which will allow us to not only demonstrate the usage of the LFRB, but also to verify the correctness of the code.

This test driver is uncomplicated: in the main task it sets up the LFRB with a 20 byte buffer, after which it begins to read 8 byte sections. This will trigger the LFRB to begin requesting data from the data request task, with this data request task setting an end-of-file (EoF) state after writing 100 bytes. The main task will keep reading 8-byte chunks until the LFRB is empty. It will also compare the read byte values with the expected value, being the value range of 0 to 99.

Test Driver

The Ada version of the test driver for the LFRB can be found in the same GitHub project as the C++ version. The file is called test_databuffer.adb and can be found in the ada/reference/ folder. The Makefile to build the reference project is found in the /ada folder, which requires an Ada toolchain to be installed as well as Make. For details on this aspect, see the first article in this series. When running make in the folder, the build files are placed under obj/ and the resulting binary under bin/.

The LFRB package is called LFRingDataBuffer, which we include along with the dataRequest package that contains the data request task. Obviously, since typing out LFRingDataBuffer over and over would be tiresome, we rename the package:
with LFRingDataBuffer;
with dataRequest; use dataRequest;

procedure test_databuffer is
package DB renames LFRingDataBuffer;
[..]
After this we can initialize the LFRB:
initret : Boolean;
[..]
initret := DB.init(20);
if initret = False then
put_line("DB Init failed.");
return;
end if;
Before we start reading from the LFRB, we create the data request task:
drq : DB.drq_access;
[..]
drq := new dataRequestTask;
DB.setDataRequestTask(drq);
This creates a reference to a dataRequestTask instance, which is found in the dataRequest package. We pass this reference to the LFRB so that it can call entries on it, as we will see in a moment.

After this we can start reading data from the LFRB in a while loop:
bytes : DB.buff_array (0..7);
read : Unsigned_32;
emptied : Boolean;
[..]
emptied := False;
while emptied = False loop
read := DB.read(8, bytes);
[..]
if DB.isEoF then
emptied := DB.isEmpty;
end if;
end loop;
As we know what the value of each byte we read has to be, we can validate it and also print it out to give the user something to look at:
idx : Unsigned_32 := 0;
[..]
idx := 0;
for i in 0 .. Integer(read - 1) loop
put(Unsigned_8'Image(bytes(idx)) & " ");
if expected /= bytes(idx) then
aborted := True;
end if;

idx:= idx + 1;
expected := expected + 1;
end loop;
Of note here is that put() from the Ada.Text_IO package is similar to the put_line() procedure except that it doesn’t add a newline. We also see here how to get the string representation of an integer variable, using the 'Image attribute. For Ada 2012 we can use it in this fashion, though since 2016 and in Ada 2022 we can also use it directly on a variable, e.g.:
put(bytes(idx)'Image & " ");
Finally, we end the loop by checking both whether EoF is set and whether the buffer is empty:
if DB.isEoF then
emptied := DB.isEmpty;
end if;
With the test driver in place, we can finally look at the LFRB implementation.

Initialization

Moving on to the LFRB’s implementation file (lfringdatabuffer.adb), we can in the init procedure see a number of items which we covered in the previous article already, specifically the buffer type and its allocation, as well as the unchecked deallocation procedure. All of the relevant variables are set to their appropriate value, which is zero except for the number of free bytes (since the buffer is empty) and the last index (capacity – 1).

Flags like EoF (False) are also set to their starting value. If we call init with an existing buffer we first delete it before creating a new one with the requested capacity.

Reading

Simplified layout of a ring buffer.
Moving our attention to the read function, we know that the buffer is still empty, so nothing can be read from the buffer. This means that the first thing we have to do is request more data to fill the buffer with. This is the first check in the read function:
if eof = false and len > unread then
put_line("Requesting data...");
requestData;
end if;
Here len is the requested number of bytes that we intend to read, with unread being the number of unread bytes in the buffer. Since len will always be more than zero (unless you are trying to read zero bytes, of course…), this means that we will call the requestData procedure. Since it has no parameters we omit the parentheses.

This procedure calls an entry on the data request task before waiting for data to arrive:
dataRequestPending := True;
readT.fetch;

while dataRequestPending = True loop
delay 0.1; -- delay 100 ms.
end loop;
We set the atomic variable dataRequestPending which will be toggled upon a write action, before calling the fetch entry on the data request task reference which got passed in from the test driver earlier. After this we loop with a 100 ms wait until the data has arrived. Depending on the context, having a time-out here might be desirable.

We can now finally look at the data request task. This is found in the reference folder, with the specification ([url=https://github.com/MayaPosch/LockFreeRingBuffer/blob/master/ada/reference/dataRequest.ads]dataRequest.ads[/url]) giving a good idea of what the Ada rendezvous synchronization mechanism looks like:
package dataRequest is
task type dataRequestTask is
entry fetch;
end dataRequestTask;
end dataRequest;
Unlike an Ada task, which is auto-started with the master task to which the subtask belongs, a task type can be instantiated and started at will. To communicate with the task we use the rendezvous mechanism, which presents an interface (entries) to other tasks that are effectively like procedures, including the passing of parameters. Here we have defined just one entry called fetch, for hopefully obvious reasons.

The task body is found in [url=https://github.com/MayaPosch/LockFreeRingBuffer/blob/master/ada/reference/dataRequest.adb]dataRequest.adb[/url], which demonstrates the rendezvous select loop:
task body dataRequestTask is
[..]
begin
loop
select
accept fetch do
[..]
end fetch;
or
terminate;
end select;
end loop;
end dataRequestTask;
To make sure that the task doesn’t just exit after handling one call, we use a loop around the select block. By using or we can handle more than one call, with each entry handler (accept) getting its own section so that we can theoretically handle an infinite number of entries with one task. Since we only have one entry this may seem redundant, but to make sure that the task does exit when the application terminates we add an or block with the terminate keyword.

With this structure in place we got a basic rendezvous-enabled task that can handle fetch calls from the LFRB and write into the buffer. Summarized this looks like the following:
data : DB.buff_array (0..9);
wrote : Unsigned_32;
[..]
wrote := DB.write(data);
put_line("Wrote " & Unsigned_32'Image(wrote) & HT & "- ");
Here we can also see the way that special ASCII characters are handled in Ada’s Text_IO procedures, using the [url=https://en.wikibooks.org/wiki/Ada_Programming/Libraries/Ada.Characters.Latin_1?useskin=vector]Ada.Characters.Latin_1[/url] package. In this case we concatenate the horizontal tab (HT) character.

Skipping ahead a bit to where the data is now written into the LFRB’s buffer, we can read it by first checking how many bytes can be read until the end of the buffer (comparing the read index with the buffer end index). This can result in a number of of outcomes: either we can read everything in one go, or we may need to read part from the front of the buffer, or we have fewer bytes left unread than requested. These states should be fairly obvious so I won’t cover them here in detail, but feel free to put in a request.

To take the basic example of reading all of the requested bytes in a single chunk, we have to read the relevant indices of the buffer into the bytes array that was passed as a bidirectional parameter to the read function:
function read(len: Unsigned_32; bytes: in out buff_array) return Unsigned_32 is
This is done with a single copy action and an array slice on the (dereferenced) buffer array:
readback := (read_index + len) - 1;
bytes := buffer.all(read_index .. readback);
We’re copying into the entire range of the target array, so no slice is necessary here. On the buffer array, we start at the first unread byte (read_index), with that index plus the number of bytes we intend to read as the last byte. Minus one due to us starting the array with zero instead of 1. This would be a handy optimization, but since we’re a stickler for tradition, this is what we have to live with.

Writing

Writing into the buffer is easier than reading, as we only have to concern ourselves with the data that is in the buffer. Even so it is quite similar, just with a focus on free bytes rather than unread ones. Hence we start with looking at how many bytes we can write:
locfree : Unsigned_32;
bytesSingleWrite: Unsigned_32;
[..]
locfree := free;
bytesSingleWrite := free;
if (buff_last - data_back) < bytesSingleWrite then
bytesSingleWrite := buff_last - data_back + 1;
end if;
We then have to test for the different scenarios, same as with reading. For example with a straight write:
if data'Length <= bytesSingleWrite then
writeback := (data_back + data'Length) - 1;
buffer.all(data_back .. writeback) := data;
elsif
[..]
end if;
Of note here is that we can obtain the size of a regular array with the 'Length attribute. Since we can write the whole chunk in one go, we set the slice on the target (the dereferenced buffer) from the write index (data_back) to (and including) the size of the data we’re writing (minus one, because tradition). If we have to do partial copying of the data we need to use array slices here as well, but here it is only needed on the buffer.

Finally, we have two more items to take care of in the write function. The first is letting the data request procedure know that data has arrived by setting dataRequestPending to false. The other is to check whether we can request more data if there is space in the buffer:
if eof = true then
null;
elsif free > 204799 then
readT.fetch;
end if;
There are a few notable things in this code. The first is that Ada does not allow you to have empty blocks, but requires you to mark those with null. The other is that magic numbers can be problematic. Originally the fixed data request block size in NymphCast was 200 kB before it became configurable. If we were to change the magic number here to e.g. 10 (bytes), we’d call the fetch entry on the data request task again on the first read request, getting us a full buffer.

EoF

With all of the preceding, we now have a functioning, lock-free ring buffer in Ada. Obviously we have only touched on the core parts of what makes it tick, and skimmed over the variables involved in keeping track of where what is going and where it should not be, not to mention how much. Much of this should be easily pieced together from the linked source files, but can be expanded upon, if desired.

Although we have a basic LFRB now, the observing among us may have noticed that most of the functions and procedures in the Ada version of the LFRB as located on GitHub are currently stubs, and that the C++ version does a lot more. Much of this functionality involves seeking in the buffer and a number of other tasks that make a lot of sense when combined with a media player like in NymphCast. These features will continue to be added over time as the LFRB project finds more use, but probably aren’t very interesting to cover.

Feel free to sound off in the comments on what more you may want to see involving the LFRB.

[mitxela] has a tiny problem, literally: some of his projects are so small as to defy easy programming. While most of us would probably solve the problem of having no physical space on a board to mount a connector with WiFi or Bluetooth, he took a different path and gave this clever light-based programming interface a go.

Part of the impetus for this approach comes from some of the LED-centric projects [mitxela] has tackled lately, particularly wearables such as his LED matrix earrings or these blinky industrial piercings. Since LEDs can serve as light sensors, albeit imperfect ones, he explored exactly how to make the scheme work.

For initial experiments he wisely chose his larger but still diminutive LED matrix badge, which sports a CH32V003 microcontroller, an 8×8 array of SMD LEDs, and not much else. The video below is a brief summary of the effort, while the link above provides a much more detailed account of the proceedings, which involved a couple of false starts and a lot of prototyping that eventually led to dividing the matrix in two and ganging all the LEDs in each half into separate sensors. This allows [mitxela] to connect each side of the array to the two inputs of an op-amp built into the CH32V003, making a differential sensor that’s less prone to interference from room light. A smartphone app alternately flashes two rectangles on and off with the matrix lying directly on the screen to send data to the badge — at a low bitrate, to be sure, but it’s more than enough to program the badge in a reasonable amount of time.

We find this to be an extremely clever way to leverage what’s already available and make a project even better than it was. Here’s hoping it spurs new and even smaller LED projects in the future.

youtube.com/embed/IHD3ji-F600?…

Dal 17 al 19 giugno 2024, Lisbona, Portogallo, ha ospitato un evento interregionale senza precedenti come parte della sesta fase del #SEACOP, dedicato alla lotta al traffico marittimo illecito.
Ospitato dall'Agenzia europea per le droghe (ex Osservatorio europeo per le droghe e le tossicodipendenze), questo evento aveva il titolo "Dall'America all'Africa: cooperazione globale per interrompere la nuova rotta marittima illecita".
Ha riunito oltre 80 funzionari di alto livello e stakeholder chiave da oltre 20 paesi, tra cui rappresentanti dei Caraibi, dell'America Latina e dell'Africa occidentale, insieme a partner europei e internazionali.
L'incontro mirava a promuovere la cooperazione globale per identificare e, in ultima analisi, interrompere le nuove rotte di navigazione illecite lungo l'asse transatlantico. Questa iniziativa collaborativa riflette un impegno condiviso per rafforzare la cooperazione globale nella
lotta contro la criminalità organizzata e proteggere i domini marittimi.

Dal seminario è emerso che le principali sfide nella lotta contro il traffico Illecito in Europa vengono prima di tutto dal volume di merce: l'enorme quantità di merci che entra in Europa rende difficile monitorare e controllare tutti i container, dalla vulnerabilità dei porti: alcuni porti sono più suscettibili al traffico illecito, offrendo opportunità ai gruppi criminali nonchè dalla mancanza di armonizzazione legislativa: le differenze nelle leggi tra i paesi europei permettono ai trafficanti di sfruttare le lacune legali per coordinare le loro operazioni.
Interessante l'aspetto riferito ad una Iitegrazione efficace delle donne nelle Forze dell'Ordine, attraverso formazione e mentoring offrendo programmi di formazione specifici e opportunità, nonchè l' adattamento degli strumenti fornendo attrezzature e risorse adeguate alle esigenze delle donne per migliorare la loro efficacia operativa e la promozione della diversità, favorendo una cultura inclusiva che riconosca il valore delle donne nel costruire relazioni di fiducia con le donne coinvolte nelle reti criminali.
Infine si è discusso delle tecnologie avanzate per il monitoraggio e la sicurezza nei porti europei, per mezzo dei sistemi di tracciamento automatico grazie all' utilizzo di radar marini e sistemi di tracciamento automatizzati per monitorare le navi in tempo reale, droni e satelliti per sorvegliare aree difficili da raggiungere e raccogliere dati e tecnologie di scansione e analisi dati, implementando scanner e tecnologie di intelligenza artificiale per analizzare i dati e identificare attività sospette.