Hacker Public Radio

This show has been flagged as Clean by the host.









01 Introduction







This is the sixth episode in an 8 part series.







02



In the previous episode we looked at I/O modules, what they are, how they work, and the purpose that they serve in the system.







We also discussed machine safety systems and also claims made by certain people about cyber security and industrial safety.







In this episode we will look at PLC networking, together with a detailed look at one network protocol, Modbus.















03 Types of Networks



PLC networks fall into three broad categories, based on the purpose of the network.



These categories are







• PLC to IO



• PLC to PLC



• and PLC to PC or Personal computer.







There is a great deal of overlap between these, so don't expect them to fall into nice discrete pigeonholes.







04 A Multiplicity of Protocols



Logically, you would think that the advantages of interoperability would be so great that there would be just a few networking protocols and everyone would use them.



The reality is the opposite.



There is such a multitude of protocols that I won't attempt to list them all.



Industrial automation is a market that is firmly in the control of the vendors, not the customers, and the vendors value customer lock in over user benefits.







05



What I will focus on instead is the technological development over time so you can understand how we ended up where we are today.



I will illustrate this with a few protocols from a few vendors before going into detail on one specific family of networks.















06 Basic Point to Point Serial



The first and most basic networks were simple point to point serial links.



You may argue that a point to point link is not a network, but in this case it is the start of networking with PLC, and one of the most important industrial network protocols today is a direct descendent of one of the early point to point protocols.







07



These point to point links initially addressed two main issues.



One was that once computers were being used to run the software needed to program PLCs, some means of downloading the program to the PLC and to debug the PLC program was needed, and this took place over a point to point serial link.







08



The other was that there were various microprocessor driven instruments and devices where it was desirable to allow the PLC to communicate with them in order to obtain readings, adjust set points, and otherwise exchange data.



A serial link was the obvious means of implementing this.







The physical and electrical media were generally RS-232, RS-422, or serial current loop.







09 RS-232



RS-232 should be familiar to most listeners.



The notable characteristic of RS-232 is that the data and control signals were referenced to ground, or "single ended" as this is also known.



While this was simple, it placed limitations on length of cabling and it was somewhat problematic when the PLC and the other device were connected to different power sources and did not have a common ground.







10 RS-422



RS-422 differs from RS-232 in that the signals are differential rather than referenced to a common ground.



Signal lines come as pairs, and it is the difference in voltage within the pair rather than compared to ground which defines the zeros and ones.



This allows for higher data rates, up to 10 mbps at very short distances, and much longer cable runs, up to 1,200 metres, at the cost of lower data rates.







11



RS-422 also allowed for multiple receivers to be connected to the same wires, although only one driver was permitted.



This allowed for multiple devices to "listen" on the same set of wires, although only one node could "talk".







12 Serial Current Loop or TTY



Some PLCs, particularly Siemens, used a serial current loop instead of RS-232 or RS-422.



This is known as a TTY interface, as it originated with teletypes.



You may be familiar with the term TTY being used to describe terminal windows in unix like operating systems.







13



This is due to early computers adopting off the shelf teletype equipment to provide operator terminals.



This used differences in current rather than differences in voltage to carry signals.



When 20 mA is flowing, this indicates a "1".



When 0 mA is flowing, this indicates a "0".







Serial current loops can operate reliably over greater distances than RS-232, up to a kilometre at lower data rates.











14 Typical Protocols



An electrical standard such as RS-232 allows for transmitting zeros and ones through a wire.



It does not however define what those zeros and ones mean.



That requires a data protocol.







15



Each manufacturer tended to come up with their own protocol.



Modicon developed Modbus.



Allen Bradley came up with DF1.



Siemens created 3964R and RK512



Other manufacturers generally each had their own.







I will discuss Modbus in detail later, but won't otherwise go into detail on these protocols here.















16 Multi-drop Serial



Point to point serial, even RS-422 which allowed for multiple receivers, worked, but it suffered from a number of limitations.



The most obvious one is that if you wanted two way communication, you needed a separate cable between each point, and a dedicated communications port or a port multiplexer.



As the system becomes larger and more complex, this becomes unwieldy.







17 RS-485



What would be desirable is a means of allowing multiple serial devices to share a serial communications link.



The solution to this is RS-485.



Like RS-422 this uses differential signalling.



It also allows multiple receivers on the same wires.



Unlike RS-422 however, RS-485 allows for multiple transmitters.



Up to 32 nodes can be connected to the same RS-485 cable.



This limit is determined by the electrical characteristics of the cable and transmitter and receiver chips.







18 New Protocols



PLC manufacturers adapted their existing protocols or came up with new ones.



Allen Bradley adapted their serial DF1 protocol into Data Highway, Data Highway Plus, and Data Highway 485.



Siemens came up with L1, Profibus and Profibus-DP.







19 Master Slave Versus Multi-Master



Many of these networks were strictly master-slave systems.



One node would be designated the network master, and it would poll each of the other nodes, the slaves.



This sort of configuration suited a lot of applications where what was generally wanted was to allow a PLC to act as the network master and poll various other devices located some distance away.







20



One early application of this was to allow IO racks to be located some distance from the PLC CPU.



This in turn allowed for the IO racks on very large machines to be closer to the devices they are connected to, such as switches or valves or relays, and so reducing the amount of cabling and wiring required.







21



Further development of this produced IO in the form of blocks that could be mounted directly on the machine without requiring a separate electrical enclosure.



These could even be directly integrated into valve banks, which are collections of valves sharing a common plenum.







22



However, this had limitations when the goal was to network multiple PLCs together so they can coordinate with each other.



With a strictly master slave system, one of the PLCs would have to be designated as the master and the PLC program would have to handle forwarding of messages between the other PLCs.







23



The solution to this was a multi-master network.



The physical wiring would still typically be RS-485 or some proprietary variation on it.



The protocol however would have to be adapted to allow for multiple masters.



This was usually some sort of token passing protocol, where the "token", which was a piece of data designating the master, would be passed from node to node so that each node had its turn to temporarily be master.















24 Device Level Networks



The reduction in cables and wires and the resulting cost savings in terms of installation labour meant that there was additional incentive to extend networks down to individual devices such as switches or single valves.







I won't go into a lot of details on these, but instead just mention some common examples.







There were some purely proprietary systems such as Siemens ASI.







25



There were also a number of systems based on CAN, which stands for Controller Area Network.



CAN comes from the auto industry, and was meant for networking various parts of your car together.



You probably have a CAN network in your car whether you realize it or not.







26



The industrial automation industry took the off the shelf CAN standards and chip sets and added their own protocols on top to create device level networks.



Some typical examples of his are Canbus and Allen Bradley Devicenet.















27 The Rise of Ethernet



Networking appeared on the factory floor well before it was common in the factory's offices.



This combined with the highly fragmented nature of the industrial automation industry meant that it was difficult to gain economies of scale in manufacturing the networking hardware.



It also meant that each company had to dedicate R&D efforts developing things which duplicated functionality already existing elsewhere.







28



Meanwhile networking technology was spreading in office environments, and gradually consolidating around Ethernet and TCP/IP.



The huge scale of this market and the well developed standards meant that costs fell significantly due to economies of scale and competition between suppliers.







29



Seeing this development in the IT industry, automation companies decided to adopt IT networking standards wholesale, at least so far as the physical wiring and the low level protocols were concerned.



They could still use their application level protocols, maintaining vendor lock in.







30



Some typical examples of these protocols are Siemens Profinet, Allen Bradley Ethernet/IP, and Modbus/TCP, all of which were adaptations of previously existing protocols to operate on Ethernet.























31 Summary So Far







What we have covered so far in this episode is the origins of networking in industrial automation beginning with



point to point serial links,



to multidrop serial master slave networks,



to multidrop serial multi-master networks,



to the adoption of Ethernet.







You should have at this point some idea of the context within which networking operates in industry and what it is used for.







Next we will discuss one specific protocol in some detail, Modbus.















32 Modbus







Background



Modbus was created by Modicon in 1979.



If you recall from previous episodes, Modicon, now part of Schneider Electric, were one of the first companies to develop a PLC.







33



Modicon published the specification to allow third parties to implement it, making it one of the few truly open royalty free industrial automation standards.



I say "truly open", because the automation industry loves to put the word "open" in their brand names, although to them "open" means applying for a license, being accepted by them, paying royalties or membership fees, and paying for certification as an accepted vendor.







34



Anyone however can download the Modbus specification, implement it, and do whatever they wish with it.



There are multiple free software implementations of Modbus libraries.







35 Versions or Variants of Modbus







There are several variants of Modbus, differentiated by the physical media or application.



These are







• Modbus RTU



• Modbus ASCII



• Modbus Plus



• and Modbus TCP







36 Modbus RTU



This is the original version of Modbus, and is a point to point serial communications protocol.



The RTU part of the name stands for "Remote Terminal Unit", which is the name for an industrial device which has some sort of serial or network interface and acts as an interface to field instrumentation.



A typical example may be say a flow meter on a pipeline.



This protocol was very widely implemented by third parties.







37



The serial data format is



• 8 bit binary



• 1 start bit



• 8 data bits, least significant bit first



• 1 parity bit



• 1 stop bit







A 16 bit cyclic redundancy check field is included in the message.







38 Modbus ASCII



Modbus RTU is designed as a serial protocol and has very precise per bit timing specifications.



This meant however that it would not work reliably over radio links servicing things such as water systems, oil fields, and other distributed applications.



Furthermore, Modbus RTU is a binary protocol, and this meant that some values may be interpreted as control codes by the transmitting or receiving hardware.







39



The solution to this was Modbus ASCII.



This sent data in ASCII format, with each byte converted to two bytes of hexadecimal.



The serial timing restrictions were relaxed to effectively whatever the hardware would tolerate.







40



The serial format is



• Hexadecimal, ASCII characters 0-9 and A-F



• 1 start bit



• 7 data bits, least significant bit sent first



• 1 parity bit



• 1 stop bit







41



A colon is used to signal the start of a new message, and a carriage return and line feed pair marked the end of a message.



A longitudinal redundancy check was included as ASCII encoded data and placed just before the terminator characters.







42



Since Modbus ASCII messages took twice the number of bytes as Modbus RTU, it could only transmit data at half the speed. This meant that the use of Modbus ASCII was limited to just the applications it was meant for, which was radio communication links.







43 Modbus Plus



Modbus Plus is Modbus adapted to work on an RS-485 serial multidrop network.



However, it was never part of the Modbus specification, and was proprietary to Modicon.



I won't bother describing any more of it.







44 Modbus TCP



Modbus TCP is Modbus RTU slightly modified to be tunnelled over TCP/IP, particularly on Ethernet.



This was very widely adopted, and even some of the big vendors who had their own protocols would offer it as an alternative to allow communication with devices they would otherwise not be able to talk to.







45



Modbus TCP uses port 502.



This is an officially assigned port, and if you look up the official list of TCP ports you will find Modbus listed there as 502, just like HTTP is port 80 and SMTP email is port 25.







46



The standards committee for Modbus made the very conscious decision to adopt IT industry standards and conventions wholesale as much as possible and just reference those instead of maintaining a unique automation industry set of standards and conventions.



This was for several very practical reasons.







47



One was that there were very few people involved in standards work and they were looking for ways to reduce the amount of work they needed to do.



The other was that people working in industry found the duplication of vocabulary very confusing and difficult to keep straight as to what in IT terms translated to what in industrial automation speak.







48



One of the consequences of this is that the master - slave serial communications terms were dropped in favour of the IT networking terms client - server.



As a result of this I will use the Modbus TCP terms in the rest of this episode, as this is the form of Modbus you are most likely to encounter these days.







49 Modbus UDP



This was an unofficial version of Modbus TCP which simply sent the data over UDP rather than TCP.



There was no change to the actual Modbus data format sent.



It was done mainly to show that it could be done.



The supposed advantage was the lower overhead and latency of UDP compared to TCP, but it wasn't enough of an advantage for this to spark much interest.







50 Proprietary Modbus Extensions



Several companies created their own extensions to Modbus, particularly to extend Modbus RTU.



These were only ever used in some niche applications.



One of the most common was Enron Modbus, which was created by the Enron company in the US.



This added a 32 bit data extension to the protocol.















51 Modbus Data Model



The Modbus data model is centred around a PLC style data table.



This is an array of memory and a set of commands to read from and write to that memory.







52



There are four types of memory



• Discrete Inputs



• Coils



• Input Registers



• Holding Registers







53



There can be up to 65,536 memory addresses of each of the four types.



Each memory type can have anywhere from zero to the maximum number of elements, it is up to the implementation as to how many addresses to have.



Memory addresses start at 1, so that the number "1" refers to the first address.



Addresses as actually sent over the wire however start at "0".







54



Discrete inputs and Input registers are read only memory,



while coils and holding registers are read - write memory.







Discrete inputs and coils are single bits.



That is, each address represents one bit of memory.







55



Input and holding registers are 16 bit words.



When transmitted over the network, words are "big endian".



That means that the upper byte of a word is sent first and the lower byte is sent second.







56



It is permitted to overlay different types of memory.



For example, the coils memory could be overlaid on the holding register memory, such that for example the first 16 coils are also the first holding register, etc.















57 Modbus Functions



Modbus TCP is a client server protocol.



The client sends a command requesting to read or write memory, and the server responds with either an acknowledgement or with another message containing the requested data or an error code.







Each command is known as a "function".



Each function is referenced to by a number.







58



I won't list all of the functions, just the most commonly used ones.



A Modbus instance does not need to implement all possible functions, only the ones that it uses.







59



• Function 1 is "read coils".



• 2 is read discrete inputs.



• 3 is read holding registers.



• 4 is read input registers.



• 5 is write single coil.



• 6 is write single register.



• 15 is write multiple coils.



• 16 is write multiple registers.







60



The limits on the quantity of data elements which can be used in a single transaction for each command are as follows .



• Function 1 is 1 to 2000



• 2 - 1 to 2000



• 3 - 1 to 125



• 4 - 1 to 125



• 5 - NA



• 6 - NA



• 15 - 1 to 1968



• 16 - 1 to 123



















61 Modbus Message Format



The full Modbus message is called the ADU, or Application Data Unit.



Within the ADU is the Protocol Data Unit, or PDU.



The PDU contains the Modbus command and the associated data.



The ADU contains additional information, and can vary depending on the type of Modbus.



I will limit myself to talking about Modbus TCP here.







62 MBAP Header



On Modbus TCP, the PDU is preceded by the MBAP Header, which is the Modbus Application Protocol Header.



It has the following format.



• The first 2 bytes are the Transaction Identifier.



• The second 2 bytes are the Protocol Identifier.



• The third 2 bytes are the Length.



• The next 1 byte is the Unit Identifier.







63



The Transaction Identifier is simply an integer that will be copied from the client request to the server response.



The client can examine this to match up responses with requests.



This is really only of use if there is a chance that responses may get out of order.







64



The Protocol Identifier is always zero and indicates the protocol is Modbus.







The length is the number of following bytes, including the unit identifier and data fields.







65



The Unit Identifier is used for allowing messages to pass between Modbus TCP and serial Modbus, such as Modbus RTU.



For example, a gateway on the Modbus TCP network may have multiple Modbus RTU devices connected to it.



The Unit Identifier in this case would correspond to the serial line address or serial port number of the Modbus RTU unit the request is directed to.







66



The length field is set by the client in the case of a request, or the server in the case of a response.



All of the other fields are simply copied from the request to the response by the server.











67 Example - Function 1



Here is an example of a Modbus PDU message for function 1, read coils.







68



The request has the following format.



• The first byte is the function code, in this case it is "1".



• The next two bytes contain the starting address in the range of 0 to 65535.



• The next two bytes contain the quantity of coils, which may be in the range of 1 to 2000.







69



The response is in the following format.



• The first byte is the function code, in this case it is "1".



• The second byte is the number of bytes of data following.



• Following next is a series of bytes containing the data, with 8 coils packed into each byte, for however many bytes are required.



• Any unused bits in the final byte are padded with zeros.







70



If there was an error, the response would be in the following format.



• The first byte would be the function code with 128, or 80 in hex, added to it. This effectively sets the high bit in the byte.



• The second byte will contain an error code indicating what the error was. This will be 1, 2, 3, or 4.















71 Exception Codes



In the event of an error in the request, the function code is returned with 128 added to it, setting the high bit.



Valid function codes are all below 128, so any response which begins with 128 or higher indicates an error.







Following the error code will be the exception code.







1 - Function code not supported.



2 - Address out of range.



3 - Quantity out of range, or invalid value (in the case of functions 5 and 6).



4 - Other error.







All possible word values are valid in the case of function 6 (which is write single register), so technically exception 3 cannot occur, but it is in the spec anyway.















72



As you can see, Modbus TCP is a very simple and well defined application protocol which is well suited to industrial control.



These basic commands will do nearly all of what is required in most applications.



Because this protocol is freely available and easy to implement, it has widespread support, particularly among smaller or specialized vendors.















73 Conclusion







In this episode we took a brief look at PLC networking, together with a detailed look at one network protocol, Modbus.







In the next episode, we will look at



• Personal computers in industry, including specialized hardware,



• SCADA systems,



• HMI systems,



• Test and measurement systems,







74



This has been the sixth episode in an 8 part series.













Provide feedback on this episode.

This show has been flagged as Clean by the host.

Hi, This is Archer72 for another episode of Hacker Public Radio!







In this episode, I follow up on a question from Kevie and Ken on hpr4741 HPR Community News for September 2026.







First, a disclaimer. This is not the real me, but a clone of my voice, which only took 30 second of my sample voice using Voicebox and Docker. More on this at a later date.







Now, the question was brought up on whether the HF antenna was 15 metres above the roofline or 15 metres total.



The TLDR is that the entire antenna reaches 15 metres from the ground, with approximately 6 metres being the whip antenna above the roofline.







How did I come about this conclusion? I will not share the address of my Radio friend, but I search it on Google maps for the ground picture, and used this in Gemini AI to determine the parameters base on a 1940’s house.



Now I will go on a tangent, and you the listener can stop here if you like, where I share some ideas from Gemini AI.



So here is what what Gemini found about the house style of the 1940’s







My query was:







Average height of a two story house in meters of houses in Falmouth Kentucky from the 1940’s







And the answer:







A typical two-story home constructed in rural Kentucky during the 1940s stands 6.1 to 7.3 meters (20 to 24 feet) tall from the ground to the roof ridge.







If measuring only to the eaves / gutter line, the height is approximately 4.5 to 5.2 meters (15 to 17 feet).







Breakdown of standard 1940s residential construction specs:







1st Floor Ceiling Height: ~2.44 m (8 ft standard full dimensional stud length)







Inter-floor Framing (Joists & Subfloor): ~0.30 to 0.38 m (1 to 1.25 ft)







2nd Floor Ceiling Height: ~2.44 m (8 ft)







Foundation / Crawlspace Clearance: ~0.30 to 0.61 m (1 to 2 ft above grade)







Roof Ridge (Gable/Hip Pitch): ~1.22 to 1.83 m (4 to 6 ft above upper ceiling line)







Note on Regional & Era Variations: Mid-century wood-frame houses (such as Cape Cods, Minimal Traditional homes, or simple



American Foursquares built post-WWII) prioritized material efficiency, utilizing standard 8-foot ceiling framing rather than the higher 9-to-10-foot ceilings common in pre-1920s Victorian or Colonial builds.







Next query on antenna height:







This is a picture of the antenna in Falmouth, Kentucky.



The house was built in the 1940’s.



Estimate the height of the house and the attached antenna.







Answer:







Based on visual scale estimates using standard architectural features:







Estimated Heights







House Height (Ground to Peak): ~22 – 25 feet (6.7 – 7.6 m)







Typical standard 1.5-story or 2-story home construction: ~8-foot ceiling per story plus floor joists, foundation wall (~1–2 ft visible above grade), and roof pitch.







Mast / Push-up Pole Height: ~30 – 35 feet (9.1 – 10.7 m) total length







The mast extends from near ground level up past the lower roofline and above the main roof ridge, supported by guy wires near the top section.







Top Antenna Whip / Element: ~18 – 20 feet (5.5 – 6.1 m)







Looks like a standard 1/2 wave or 5/8 wave vertical antenna (or a 10/11-meter CB/ham vertical such as an A99/I-10K or similar base station vertical).







Total Overall System Height (Ground to Tip): ~45 – 50 feet (13.7 – 15.2 m)







Note: Visual estimates from single 2D perspective photos carry a margin of error of approximately ±10–15%.







This sounds right.







Top Antenna Whip / Element is intended for 20m, 40m and 80m HF Ham radio transmission.



That makes sense—for HF bands like 20m, 40m, and 80m, getting that vertical element up around 45 to 50 feet total off the ground gives it a much better launch angle, especially for DXing or clearing nearby obstructions.







If it’s set up with a base tuner or trap loading to cover those lower frequencies (especially 40m and 80m), having that sturdy push-up mast and guy wire support is crucial given the wind load at that height.







Clone 'me':







That’s all I have for now.







This has been Archer72’s clone.







Tune in tomorrow for another episode of Hacker Public Radio.







Bye.







References:









Zillow home value estimator










Gemini AI










Voicebox : The open-source AI voice studio








Clone, dictate and create.







Clone voices, generate speech across seven TTS engines, dictate into any app, and talk to agents in voices you own. A free and local alternative to ElevenLabs and WisprFlow, running entirely on your machine.







Ham bands used



20m, 40m and 80m HF







Preview of Voicebox















Provide feedback on this episode.

This show has been flagged as Explicit by the host.

#for_hpr





We are material beings




(00:40)
FOR CONTEXT




I was thinking about this subject as I felt great happinness for being able to go to the gym. The circumstances of having stopped exercising, and the timing of coming back, added to the joy of the exercise, so, although I had a tough week, “
gymming
” on Friday night was like a special gift.







(1:05)
BEING MATERIAL




I am a believer, and it does not matter the specific faith. It does matter that, although seeing above, I am
soo, sooo
affected by the circumstances. By my body reactions, molecular and chemical interactions that occur naturally with a sunbath, a cup of coffee or, for the sake of this episode, exercising.





It is natural
, I am saying that and maybe you already knew it; so, “what’s the problem?” It is that I am so (and sooo) circumstantial, that I feel better doing something my body likes than doing something good to a stranger — and my faith, that I believe, puts
this
in front, in terms of importance, of that.



At the same time, I am a forgetter, a person that forgets. My feeling for someone or something now can move from A to Z, from alpha to omega, in an instant, moved by the impulse of a phrase listened to, the infusion of an aroma of the atmosphere, something I remembered, or by nothing at all.







(2:39)
ARE


WE


MATERIAL ?




I think chemical and physical reactions affect everybody (everybody-ah!), and feelings vary. No?



I think I am overreactive to circumstances, as a trace of character that it may be, or I am super reactive to external and internal occurrences. Very varying. So much an effect of causes, the perfect example of any cause-effect theory. Someone you can trust one day, that may be another person tomorrow.







(3:20)
TETRAPLEGIA




That may say something of the admiration more people tend to have about a quadriplegic person that lives well, than about a not disable person living equally well.



As if the person with a visible problem is a miracle if she is happy, because we could expect her not to be efficient and up and going.



Not a critic, it’s a way to understand why only Joni Eereckson Tada could do the radio shows she has been doing.



Her phrases and perspectives are valid in their context, affects the listener that knows her limitations; it couldn’t be anyone.



The power is transmitted by the full life in a disabled body. And by what is learnable by it, in benefit of people in different circumstances.







Certainly, if we talk about feelings tied to the body, and having a body that one can barely move, only some members, there is a shock, an equation that is an inequation: feelings, and will, and living fully, in times like that, must come from another source, not only the body and the health and having days without pain.



Me, by myself, if I have pain, body limitation, or have another people not accepting my ideas or work, I’m down. I may be, in one hour, in plain communion with the object of my faith; if, the moment after, happens one of those down things,
cruchê
(onomatopoeia to things down,
kaput
).







(5:24)
ANOTHER EXAMPLE OF SUFFERING IN BELIEF




If I can add a topic to this discussion, it’s not a privilege of
one
faith to “exalt” suffer. One example is José Arigó, a Brazilian guy that, in the 1950s, started to heal patients from around the country; without having studied medicine, he operated thousands of people that came to him, while saying he was taken by Doctor Fritz. He served from Monday to Monday, no rest, while still working as an employee of the social security — as he did before coming to this religion —, to nourish his house, his wife, his family. He received no money for the healings.







As by me, I accomplish no mission, but, as a human and material (circumstantial) being, I feel well when coming to a difficult path where, with all help, I survive (while trying to obey the order of happiness, not only being alive). Be it a relational, a financial, any kind of hunger or apparent despair. Not necessarily, as I say, overcoming it, or not immediately, but passing by, passing though, helped greatly-greatly, as I need; and it’s fantastic.









Bye
.

Provide feedback on this episode.

This show has been flagged as Explicit by the host.

Blender -
https://www.blender.org/








Python -
https://www.python.org/








Anthropic Claude -
https://claude.ai








Linden Lab SecondLife -
https://secondlife.com/








Go Language -
https://go.dev/














Apologies for squirrels and silliness, no mystical middle-earth beings were harmed in the making of this episode


Provide feedback on this episode.

This show has been flagged as Clean by the host.


TOOOL




T


he


O


pen


O


rganisation


O


f


L


ockpickers



https://toool.nl/Toool





MIT Guide to Lock Picking:


https://www.lockwiki.com/index.php/MIT_Guide_to_Lock_Picking









Provide feedback on this episode.