- Joined
- Jun 12, 2017
- Messages
- 30
- Reaction score
- 140
A few weeks ago I posted in the CC a template of 2 modules for wireless ship identification (https://starmadedock.net/content/uensa-tm-84-id.7576/). But those modules, that are basically radios, have a big flaw : sometime the wireless blocks don't respond too well so data was lost quite often resulting in incorrect reads.
Even if it's originaly made only for my UENSA Project (I'll post about it as soon as I will have a few more assets ready) and RP purposes, it was still way to laggy and unreliable.
So following that work I created a new set of radios (mainly made for ship ID but it can be actually used for any kind of communication) that are way more reliable and now that are modular. So it's actually a kit of templates for building complex and automated logic radios.
It can be found here : https://starmadedock.net/content/4-bit-rk.7610/
And that is the thread that will explain how all of it works.
To make it more clear I will subdivide that manual in 5 chapters :
- 1 : Introdution
- 2 : Modules documentation
- 3 : Protocol naming
- 4 : Examples
- 5 : Conclusion
Let's go!
Even if it's originaly made only for my UENSA Project (I'll post about it as soon as I will have a few more assets ready) and RP purposes, it was still way to laggy and unreliable.
So following that work I created a new set of radios (mainly made for ship ID but it can be actually used for any kind of communication) that are way more reliable and now that are modular. So it's actually a kit of templates for building complex and automated logic radios.
It can be found here : https://starmadedock.net/content/4-bit-rk.7610/
And that is the thread that will explain how all of it works.
To make it more clear I will subdivide that manual in 5 chapters :
- 1 : Introdution
- 2 : Modules documentation
- 3 : Protocol naming
- 4 : Examples
- 5 : Conclusion
Let's go!
4 Bit RK (Radio Kit) is a set of 18 templates for building modular wireless radio systems that send at a time a string of 4 usable bits to whatever purpose you need.
There are several classes of modules that can be used with minimal external logic added and minimal user action needed. I started from the idea that there is only one trigger (to ask something) and all the rest is automated.
While there is only 4 usable bits that are send the system actually uses 9 bit for each message (a message is considered a single 4 bit string, there will examples of 2 string communication or 8 bits later).
2 bits are for the start/stop bit making it possible to detect the message, as I already said 4 usables bits and 3 parity bits.
Those last 3 bits add redundance to the message so that if a single bit is changed/missed during a transfert, thanks to them is possible to detect wich bit has been modified and correct it using the Hamming (7,4) code (Hamming code - Wikipedia).
That way even is there is a glich/bug the message can be still read correctly. Thought the system can't detect burst type errors (2 or more bits are changed) or start/stop bit errors, but those are pretty rare compared to regular errors.
Since a total of 9 bits are used with a 0.5 delay each a 4 bit message takes about 4.5 sec to transfert.
There are several classes of modules that can be used with minimal external logic added and minimal user action needed. I started from the idea that there is only one trigger (to ask something) and all the rest is automated.
While there is only 4 usable bits that are send the system actually uses 9 bit for each message (a message is considered a single 4 bit string, there will examples of 2 string communication or 8 bits later).
2 bits are for the start/stop bit making it possible to detect the message, as I already said 4 usables bits and 3 parity bits.
Those last 3 bits add redundance to the message so that if a single bit is changed/missed during a transfert, thanks to them is possible to detect wich bit has been modified and correct it using the Hamming (7,4) code (Hamming code - Wikipedia).
That way even is there is a glich/bug the message can be still read correctly. Thought the system can't detect burst type errors (2 or more bits are changed) or start/stop bit errors, but those are pretty rare compared to regular errors.
Since a total of 9 bits are used with a 0.5 delay each a 4 bit message takes about 4.5 sec to transfert.
Theses modules follow a few geometrical rules : their lenght is always a multiple of 4, height is 6 and the bottom and top layer is just hull blocks that can be removed for more compactivity (exept when there is an input matrix that use the top layer, i'll explain that a bit lower).
Out of 18 modules there are 8 classes that can be put in 2 types : passive or active.
Actives modules have a trigger button to launch an action, a reset button to put them back to their original state or both, they all have basically timers. Passives modules don't have all that and their output change (almost) instantly depending on their input.
Each class can be recognized with the collored hull on top of the modules :
- yellow : Emitter (active)
- green : Receiver (active)
- white : Isolator (active)
- blue : Decoder (passive)
- red : Processor (generally passive)
- pink : Post-Processor (generally passive)
- orange : Registry (active)
- brown : Timer (passive)
Using these classes here is the diagramm that show what are their respectives roles :
At first the trigger (buttons usualy) is , well, triggered and depending on externals Inputs (not represented) on the processor(s) a 4 bit string is generated and send to the emitter. The emitter then send the data to the receiver throught and isolator (it just isolate an incomming message to avoid interferences. The received message is then send to a decoder that will transform the 4 bit message to and input trigger that is send to another set of processor(s). These will analyse the incoming decoded message and external inputs to either generate a new message to send back or to send data to a post-processor that will create a definitive output. Then it all loops back. Registries here act as short term memory.
Timers are not represented but they are pretty much in between every modules.
This is just the genreal scheme, the most basic setting being an emitter connected to a receiver. Also, a processor can be used as a post-processor or a reciever can send data directly to a processor or another emitter, etc ... The possibilities are endless. And as you can see there is 2 wireless data streams on the chart (emitter to isolator) but of course there can be only one 2 way stream, using a common antenna for the emitter and receiver+isolator.
Now, let's get more in detail about modules functions
(4 bit string input/outputs are designated with "bit array" and the first bit is on the top, "I" means Input and "O" Output).
Out of 18 modules there are 8 classes that can be put in 2 types : passive or active.
Actives modules have a trigger button to launch an action, a reset button to put them back to their original state or both, they all have basically timers. Passives modules don't have all that and their output change (almost) instantly depending on their input.
Each class can be recognized with the collored hull on top of the modules :
- yellow : Emitter (active)
- green : Receiver (active)
- white : Isolator (active)
- blue : Decoder (passive)
- red : Processor (generally passive)
- pink : Post-Processor (generally passive)
- orange : Registry (active)
- brown : Timer (passive)
Using these classes here is the diagramm that show what are their respectives roles :
At first the trigger (buttons usualy) is , well, triggered and depending on externals Inputs (not represented) on the processor(s) a 4 bit string is generated and send to the emitter. The emitter then send the data to the receiver throught and isolator (it just isolate an incomming message to avoid interferences. The received message is then send to a decoder that will transform the 4 bit message to and input trigger that is send to another set of processor(s). These will analyse the incoming decoded message and external inputs to either generate a new message to send back or to send data to a post-processor that will create a definitive output. Then it all loops back. Registries here act as short term memory.
Timers are not represented but they are pretty much in between every modules.
This is just the genreal scheme, the most basic setting being an emitter connected to a receiver. Also, a processor can be used as a post-processor or a reciever can send data directly to a processor or another emitter, etc ... The possibilities are endless. And as you can see there is 2 wireless data streams on the chart (emitter to isolator) but of course there can be only one 2 way stream, using a common antenna for the emitter and receiver+isolator.
Now, let's get more in detail about modules functions
(4 bit string input/outputs are designated with "bit array" and the first bit is on the top, "I" means Input and "O" Output).
Module that send the 9 bits, one side has the 4 programmable bits as input, the 3 parity bit are automaticlly generated with logic.
Dimensions : 1x12 no matrix
O - Active : that output state is set to HIGH when the emitter is not transmitting
I - Trigger : button that make the emitter send a message
O - Signal : the generated full 9 bits message is outputed here with 0.5 sec allocated per bit
Dimensions : 1x12 no matrix
O - Active : that output state is set to HIGH when the emitter is not transmitting
I - Trigger : button that make the emitter send a message
O - Signal : the generated full 9 bits message is outputed here with 0.5 sec allocated per bit
Module that receive the 9 bits and process them to output the readable message of 4 bits. When enabled it waits for incoming message and once it has read one it need to be reseted to read again.
Dimensions : 3x12 no matrix
I - Enable : set to HIGH for the module to be able to accept any incoming signal
I - Reset : once a message has been detected and read, the module won't process any new incoming signal (but they will appear on the delay block array, that's why when not used it's more recommended to disable the module instead of not reseting it) until that input is triggered, it will also erase the previous message in the bit array
I - Signal : the full 9 bits message is inputed here with 0.5 sec allocated per bit
O - Read : that output state is set to HIGH when any king of message has been detected and read, it's delayed by 0.5 sec after the bit array
Dimensions : 3x12 no matrix
I - Enable : set to HIGH for the module to be able to accept any incoming signal
I - Reset : once a message has been detected and read, the module won't process any new incoming signal (but they will appear on the delay block array, that's why when not used it's more recommended to disable the module instead of not reseting it) until that input is triggered, it will also erase the previous message in the bit array
I - Signal : the full 9 bits message is inputed here with 0.5 sec allocated per bit
O - Read : that output state is set to HIGH when any king of message has been detected and read, it's delayed by 0.5 sec after the bit array
Module that when it get even a single bit input from one source, it blocks all outher input sources until it's reseted, used as anti interference. While it offer only 4 input sources, they can be chained to expand it (I tested it with a chain of 4 levels, so 256 sources, and it worked perfectly).
Dimensions : 1x8 no matrix
I - Source 1 to 4 : input signals sources
O - Out : single signal output protected from interferences
I - Reset : trigger it to reset the module so that it can accept any input source
Dimensions : 1x8 no matrix
I - Source 1 to 4 : input signals sources
O - Out : single signal output protected from interferences
I - Reset : trigger it to reset the module so that it can accept any input source
There are 5 modules here all with the same role : taking a 4 bit string as input and giving out a positive output when the message correspond to the database. There are 2 kind, 3 programmable ones, with an input matrix that let you select up to 4-8-12 differents 4-bits codes and 2 non programmable, and without an input matrix.
They are passive modules, meaning they don't need to be reseted and their output change in real-time depending on the input.
First are the 3 programmable ones (decoder-4, decoder-8, decoder-12) :
Dimensions : 4x(8-12-16) with input matrix
O - Read : that output is set to HIGH when the input bit array correspond to any one the strings in the input matrix
O - O1-12 : Each activation block is set to HIGH when the input 4-bits string correspond to 4-bits string from the input matrix (O1 for first row, O2 for the second, ...)
The first row of the input matrix is on the left in the picture, the closest to the input bit array.
Now, after those 3, there is a 4th decoder (decoder-16) that works the same, but without the input matrix since it can read all 16 differents states of the bit array, programming it is redundant.
Dimensions : 4x4 no matrix
You may think why use the 3 above when this one is smaller and takes 16 readings, that's because if you want to reconfigure what get decoded (exemple : ships's ID) you won't have to reconnect logics blocks but just activate/deactivate the activations blocks from the matrix.
The last decoder (decoder-mono) has hard wired 4 different possible readings : 1000, 0100, 0010, 0001. It accepts only one positive bit at a time and set an output activation block to HIGH in the same position of the incoming bit, for all other states of the bit array it returns nothing.
It was made specifically for the docking system protocol (I talk about it lower).
Dimensions : 1x4 no matrix
They are passive modules, meaning they don't need to be reseted and their output change in real-time depending on the input.
First are the 3 programmable ones (decoder-4, decoder-8, decoder-12) :
Dimensions : 4x(8-12-16) with input matrix
O - Read : that output is set to HIGH when the input bit array correspond to any one the strings in the input matrix
O - O1-12 : Each activation block is set to HIGH when the input 4-bits string correspond to 4-bits string from the input matrix (O1 for first row, O2 for the second, ...)
The first row of the input matrix is on the left in the picture, the closest to the input bit array.
Now, after those 3, there is a 4th decoder (decoder-16) that works the same, but without the input matrix since it can read all 16 differents states of the bit array, programming it is redundant.
Dimensions : 4x4 no matrix
You may think why use the 3 above when this one is smaller and takes 16 readings, that's because if you want to reconfigure what get decoded (exemple : ships's ID) you won't have to reconnect logics blocks but just activate/deactivate the activations blocks from the matrix.
The last decoder (decoder-mono) has hard wired 4 different possible readings : 1000, 0100, 0010, 0001. It accepts only one positive bit at a time and set an output activation block to HIGH in the same position of the incoming bit, for all other states of the bit array it returns nothing.
It was made specifically for the docking system protocol (I talk about it lower).
Dimensions : 1x4 no matrix
Processors are the main component that allow to make automated systems, by taking several inputs (decoded messages, raw messages, external data) and processing them into a new message to send with an emmiter, and most of them aren't made for general purpose.
For now there is only 2 processors : Code (basicaly a reverse decoder-16) and Dock1.0.
Code processor take 16 inputs (numbered from 1 to 16) and generate a bit string with the value inputNumber - 1
Dimensions : 4x4 no matrix
I - I1-16 : entry with it's number, do not activate several entries at the same time, it will output some messed up bitstring
The other processor, Dock1.0 is a small processor for controlling access to a dock. It has the same functions as the TM-84R-ID module in the old kit.
Dimensions : 1x4 no matrix
I - Access : set to HIGH if access to dock is autorized under normal circumstances (example : good id) and to LOW to refuse normal access
I - Dock : set to HIGH if the dock is already used or if the shipyard has no spare space
I - Lock : set to HIGH if the dock/shipyard is locked from inside
That module has priority system (in order) :
1 - system locked (output string : 0001)
2 - no access input (output string : 0100)
3 - dock used (output string : 0010)
4 - access granted (output string : 1000)
Since it's a passive module it's recommended to connect a button to the first bit (top) so that once access is granted it send a o.5 sec signal that can be used to open a dock's door or other related system.
For now there is only 2 processors : Code (basicaly a reverse decoder-16) and Dock1.0.
Code processor take 16 inputs (numbered from 1 to 16) and generate a bit string with the value inputNumber - 1
Dimensions : 4x4 no matrix
I - I1-16 : entry with it's number, do not activate several entries at the same time, it will output some messed up bitstring
The other processor, Dock1.0 is a small processor for controlling access to a dock. It has the same functions as the TM-84R-ID module in the old kit.
Dimensions : 1x4 no matrix
I - Access : set to HIGH if access to dock is autorized under normal circumstances (example : good id) and to LOW to refuse normal access
I - Dock : set to HIGH if the dock is already used or if the shipyard has no spare space
I - Lock : set to HIGH if the dock/shipyard is locked from inside
That module has priority system (in order) :
1 - system locked (output string : 0001)
2 - no access input (output string : 0100)
3 - dock used (output string : 0010)
4 - access granted (output string : 1000)
Since it's a passive module it's recommended to connect a button to the first bit (top) so that once access is granted it send a o.5 sec signal that can be used to open a dock's door or other related system.
Post-Processors (also called P-Processor) are basicaly processors modules that don't inject data back in the communication loop (if there is one), they generate a final output that may be used as input on another unrelated logic system or generate feedback/result data on displays.
For now, there is only one module of that kind, the Dock1.0 Feed P-Processor, and allow a visual feedback on a system that use the Dock1.0 processor or any compatible dock system. It's just a set of 8 screens with buttons connected to them.
Dimensions : 1x4 no matrix
When pasting that template, be sure to cut-paste the text of each display once, pasted displays usualy resets their content when triggered by logic if not cut-pasted.
For now, there is only one module of that kind, the Dock1.0 Feed P-Processor, and allow a visual feedback on a system that use the Dock1.0 processor or any compatible dock system. It's just a set of 8 screens with buttons connected to them.
Dimensions : 1x4 no matrix
When pasting that template, be sure to cut-paste the text of each display once, pasted displays usualy resets their content when triggered by logic if not cut-pasted.
These modules act as memory that communicate with processors. So if there is the need to send 2 or more messages in a single communication, instead of having 2 or more emitter configured for each message, a regitry can be used that will store all the 4 bit strings and output then one after other to a single emitter. And then on the receiver side, use another registry to save them so that they all can be processed at the same time.
There are 2 main types : Get-Registry and Set-Registry.
The first one, Get-Registry (or Reg-Get 2 or 4, can output 2 or 4 pre-set messages) output a single string at a time that can be changed changed with the next one in the input matrix until you get to the last one, where a reset is then necessary. They also integrate a counter showing which 4 bit string is being displayed.
Dimensions : 4x(4-8) with matrix
I - Reset : get back to the first string in the input matrix (can be reseted from any position)
I - Next : go to the next string in the input matrix
O - Counter : from top to bottom, it shows which string is being displayed
The input matrix here works and is oriented the same way as the matrixes in the decoders modules.
The other main kind of registries are the Set-Registry (Reg-Set 2 or 4, can save 2 or 4 messages) and those do the inverse work, they save 4 bits messages and display all saved strings at the same time in the back.
Dimensions : 4x8 no matrix
I - Reset : clear all saved strings and get back to the first position
I - Next : save a string in the current position and move to the next one
O - Counter : from top to bottom, it shows the position of the next saved string, if all postions are taken, all activations blocks are set to LOW, and a reset is necessary to be able to save a new message
O - OS1-4 : saved bit string with it's corresponding position
There is still another module, that was put in the registry category thought it doesn't save any messages, a counter that allow to count from 1 to 4 with logic. I can actually be found integrated in the others registry modules.
Dimensions : 1x8 no matrix
I - Reset : get back to the first position
I - Next : get to the next postion
O - Counter : from top to bottom, it shows the current postion
There are 2 main types : Get-Registry and Set-Registry.
The first one, Get-Registry (or Reg-Get 2 or 4, can output 2 or 4 pre-set messages) output a single string at a time that can be changed changed with the next one in the input matrix until you get to the last one, where a reset is then necessary. They also integrate a counter showing which 4 bit string is being displayed.
Dimensions : 4x(4-8) with matrix
I - Reset : get back to the first string in the input matrix (can be reseted from any position)
I - Next : go to the next string in the input matrix
O - Counter : from top to bottom, it shows which string is being displayed
The input matrix here works and is oriented the same way as the matrixes in the decoders modules.
The other main kind of registries are the Set-Registry (Reg-Set 2 or 4, can save 2 or 4 messages) and those do the inverse work, they save 4 bits messages and display all saved strings at the same time in the back.
Dimensions : 4x8 no matrix
I - Reset : clear all saved strings and get back to the first position
I - Next : save a string in the current position and move to the next one
O - Counter : from top to bottom, it shows the position of the next saved string, if all postions are taken, all activations blocks are set to LOW, and a reset is necessary to be able to save a new message
O - OS1-4 : saved bit string with it's corresponding position
There is still another module, that was put in the registry category thought it doesn't save any messages, a counter that allow to count from 1 to 4 with logic. I can actually be found integrated in the others registry modules.
Dimensions : 1x8 no matrix
I - Reset : get back to the first position
I - Next : get to the next postion
O - Counter : from top to bottom, it shows the current postion
The last 2 modules are pretty basic, they are simply a set of 4 1-sec delays, one with activations block, and the other with buttons.
Their main use is getting delays between others modules so that all data processing can happen smoothly.
Dimensions : 1x4 no matrix
Their main use is getting delays between others modules so that all data processing can happen smoothly.
Dimensions : 1x4 no matrix
Since it's a modular system, and from ship to ship, even for the same result, the arrangement of modules can vary, it become necessary to setup a naming convention, to know the capabilities of en entity equiped with it and to know which systems are compatible between themselves. I may also in the future build a 8 bits set that may be partially compatible with the 4 bits one.
The general look of a mono-loop (one question - one answer) system name will be the following :
Ha.b-Sh-c.d-NLe.f.g-Process
With the uppercase caracters being letters describing types and lowercase caracters being numbers descibing sizes and delays.
Signifiance of each part :
H : first letter describing what kind of code is used (H for Hamming code)
a.b : these two numbers show the total number of bit of a single message (excluding start/stopbits) and the number of data bits (for the current emmiter and receiver case it 7.4 since there are 3 parity bits)
S : main role of the build. S for Sender, the initial trigger is in here and the build send the data first, or R for Receiver, where the build wait at first to get a message (or severals) before replying.
h : number of parallel channels working simultaneously (for example, having 2 channels allows to send 8 bits with the same speed as sending 4 bits on a single channel, but require 2 antennas)
c.d : these two numbers show the lenght of a message send by the system, c indicate the number of strings (per channel) while d the delay between them by increments of 0.5s (that means for a delay of 0.5s d=1, for 1s d=2 and so on). They are alway present, and they have a specific value when the build send something, even as an answer from a receiver type build, but they are set to 0 when the build never send anything (in case of a simple receiver). Also, when there is only on string that is sent (c=1), just put c and ignore d.
N : indicate if the build is waiting for incomming data (either as a receiver or an answer on a sender), put N to show that no incomming data is awaited and F (feed) in the other case.
L: in case incomming data is awaited (so the previous letter is F) and the system can accept several message at a time, add this letter if the build can accept messages shorters than the number it can receive at a time (lowercase letter e)
e.f.g : if there is incomming data these 3 numbers show, in order, how many strings can be received (per channel) , the minimal delay between them and the maximal delay between them (if there is no maximum limit set it to 0). The delay value increment also by 0.5s. If there is only one string that is received (e=1), the other numbers can be ignored.
Process : a name to designate what kind of processing is used and what kind of content is send (for example Dock1.0 thanks to the processor and p-processor modules with that name)
From here, it become possible to predict if a system is compatible with another. If a sender type system without feedback send data to a receiver type with feedback, the system may work (if processors are compatible too) but the answer will be lost in the void of space. The same way, if a sender awaiting feedback communicates with a receiver without, as long as the codes/messages are compatible everything may work normally on the receiver side while the sender with wait for an answer forever (or until a reset).
To give an example, I built a fighter, the SFRU - Mako (will be put in the CC shortly) that send 8 bits of data for ship identification (with the Dock1.0 process) with 2 strings of 4 data bits (so 9 bits messages using the Hamming 7.4 code) and 1 sec delay between them. It doesn't expect any answer.
It's protocol will be then : H7.4-S1-2.2-N-Dock1.0
A station I'm still building (and works with the Mako) that identify ships using 8 data bits (only 8 bits, no 4 bit IDs) with 0.5 to 3 sec delay between strings (if those times are not respected, the system will discard the incomming communication) and no answer will have then the following protocol name : H7.4-R1-0.0-F2.1.6-Dock1.0
All the examples in the next chapter will inculde their respective protocol names.
The general look of a mono-loop (one question - one answer) system name will be the following :
Ha.b-Sh-c.d-NLe.f.g-Process
With the uppercase caracters being letters describing types and lowercase caracters being numbers descibing sizes and delays.
Signifiance of each part :
H : first letter describing what kind of code is used (H for Hamming code)
a.b : these two numbers show the total number of bit of a single message (excluding start/stopbits) and the number of data bits (for the current emmiter and receiver case it 7.4 since there are 3 parity bits)
S : main role of the build. S for Sender, the initial trigger is in here and the build send the data first, or R for Receiver, where the build wait at first to get a message (or severals) before replying.
h : number of parallel channels working simultaneously (for example, having 2 channels allows to send 8 bits with the same speed as sending 4 bits on a single channel, but require 2 antennas)
c.d : these two numbers show the lenght of a message send by the system, c indicate the number of strings (per channel) while d the delay between them by increments of 0.5s (that means for a delay of 0.5s d=1, for 1s d=2 and so on). They are alway present, and they have a specific value when the build send something, even as an answer from a receiver type build, but they are set to 0 when the build never send anything (in case of a simple receiver). Also, when there is only on string that is sent (c=1), just put c and ignore d.
N : indicate if the build is waiting for incomming data (either as a receiver or an answer on a sender), put N to show that no incomming data is awaited and F (feed) in the other case.
L: in case incomming data is awaited (so the previous letter is F) and the system can accept several message at a time, add this letter if the build can accept messages shorters than the number it can receive at a time (lowercase letter e)
e.f.g : if there is incomming data these 3 numbers show, in order, how many strings can be received (per channel) , the minimal delay between them and the maximal delay between them (if there is no maximum limit set it to 0). The delay value increment also by 0.5s. If there is only one string that is received (e=1), the other numbers can be ignored.
Process : a name to designate what kind of processing is used and what kind of content is send (for example Dock1.0 thanks to the processor and p-processor modules with that name)
From here, it become possible to predict if a system is compatible with another. If a sender type system without feedback send data to a receiver type with feedback, the system may work (if processors are compatible too) but the answer will be lost in the void of space. The same way, if a sender awaiting feedback communicates with a receiver without, as long as the codes/messages are compatible everything may work normally on the receiver side while the sender with wait for an answer forever (or until a reset).
To give an example, I built a fighter, the SFRU - Mako (will be put in the CC shortly) that send 8 bits of data for ship identification (with the Dock1.0 process) with 2 strings of 4 data bits (so 9 bits messages using the Hamming 7.4 code) and 1 sec delay between them. It doesn't expect any answer.
It's protocol will be then : H7.4-S1-2.2-N-Dock1.0
A station I'm still building (and works with the Mako) that identify ships using 8 data bits (only 8 bits, no 4 bit IDs) with 0.5 to 3 sec delay between strings (if those times are not respected, the system will discard the incomming communication) and no answer will have then the following protocol name : H7.4-R1-0.0-F2.1.6-Dock1.0
All the examples in the next chapter will inculde their respective protocol names.
Since a few good examples are worth several pages of written instructions, in the kit there is a station blueprint of a platform featuring 4 separate setups that make use of all modules types and several connection types :
- 1 : One way 4-bit identification with Dock 1.0
- 2 : Two ways 4 bit identification with Dock1.0
- 3 : One way 8-bits sending
- 4 : One way dual channel 8 bit sending
When loading it, the wireless blocks betweens entities are disconected (the senders setups are on docked platforms, but the system also works on the same entity) and need to be connected the following way :
For the first example (top-left), the wireless blocks from the emitters are directly connected from the emitters to the input sources of the isolator.
Sometime there are still errors and a reading may be wrong, but it should be pretty rare.
- 1 : One way 4-bit identification with Dock 1.0
- 2 : Two ways 4 bit identification with Dock1.0
- 3 : One way 8-bits sending
- 4 : One way dual channel 8 bit sending
When loading it, the wireless blocks betweens entities are disconected (the senders setups are on docked platforms, but the system also works on the same entity) and need to be connected the following way :
For the first example (top-left), the wireless blocks from the emitters are directly connected from the emitters to the input sources of the isolator.
Sometime there are still errors and a reading may be wrong, but it should be pretty rare.
This is a pretty basic setup where 4 ships (represented by hazard armor blocks with a single emitter) can send a 4-bit ID request to the receiver setup throught an isolator. If the id exist in the database (the decoder input matrix) then it send a signal to open one of the four docks corresponding to the ID.
A schematic of the following build will look like that :
Everything before the isolator are separate entities and on each emitter there is a different 4-bit code. The first emitter will open the first dock, the 2nd emitter opens the 2nd dock and the 4th emitter opens the 4th dock, while the 3rd emitter opens nothing since it has a wrong ID for all 4 docks, in a practical case, a single dock should be openable with several IDs.
The opening of a dock is simulated by triggering the teal row of buttons. The red and orange row of activations block represent the 2 possibles input from a dock to the Dock1.0 processor (dock is used or locked). The pink activation block enable or diable the emitter.
After a succesfull reading from the receiver, there is a delay of 1 sec before the state of the receiver is reseted. You can also see that the processor in this case act as a post-processor, since it doesn't send data back in the system.
Protocol names :
Sender : H7.4-S1-1-N-Dock1.0
Receiver : H7.4-R1-0-F1-Dock1.0
A schematic of the following build will look like that :
Everything before the isolator are separate entities and on each emitter there is a different 4-bit code. The first emitter will open the first dock, the 2nd emitter opens the 2nd dock and the 4th emitter opens the 4th dock, while the 3rd emitter opens nothing since it has a wrong ID for all 4 docks, in a practical case, a single dock should be openable with several IDs.
The opening of a dock is simulated by triggering the teal row of buttons. The red and orange row of activations block represent the 2 possibles input from a dock to the Dock1.0 processor (dock is used or locked). The pink activation block enable or diable the emitter.
After a succesfull reading from the receiver, there is a delay of 1 sec before the state of the receiver is reseted. You can also see that the processor in this case act as a post-processor, since it doesn't send data back in the system.
Protocol names :
Sender : H7.4-S1-1-N-Dock1.0
Receiver : H7.4-R1-0-F1-Dock1.0
This is a more complete setup that send 4 bits for identification and then the receiver process them and send a 4 bits message back to the sender indicating the state of the ID request. On that example it's interesting to try to change the send ID or the dock inputs (red and orange activations blocks) to see how the answer changes.
If the sender doessn't get an answer after about 5 sec (because of a wrong reading on the receiver or the receiver is disabled with the pink activation block) then the sender will diplay that it didn't get any data back.
A schematic of the following build will look like that :
By default it's setup with a right ID, so it should trigger the dock (teal button) and display "access granted"
Protocol names :
Sender : H7.4-S1-1-F1-Dock1.0
Receiver : H7.4-R1-1-F1-Dock1.0
If the sender doessn't get an answer after about 5 sec (because of a wrong reading on the receiver or the receiver is disabled with the pink activation block) then the sender will diplay that it didn't get any data back.
A schematic of the following build will look like that :
By default it's setup with a right ID, so it should trigger the dock (teal button) and display "access granted"
Protocol names :
Sender : H7.4-S1-1-F1-Dock1.0
Receiver : H7.4-R1-1-F1-Dock1.0
For most purposes sending just 4 bits isn't enougth so sending more messages in a row is necessary if we want to keep only one antenna. That build shows how to do it with a registry on which you programm the two 4 bits strings before sending starting transmitting. Another way to do it would be to have 2 emitters connected to the same antenna and one that start working after the first is finished (I actually use a setup like that on the SFRU - Mako mentionned earlier, it's even more compact, but that build is shown for the sake of example), but it become impractical and bulky if you start sending more than 2 strings in a single communication.
After being send the 2 4-bits strings are saved and displayed on some sort of screen made of activation blocks for 4 sec, after that everything is being reseted.
A schematic of the following build will look like that :
A few things can be noted here.
First of all there are 2 receivers that are connected to the same antenna (white columns in the build). They swich once one has read something (if there 4 messages 2 receivers would still be sufficient) with their enable input function. The reason there is not only one receiver is to avoid interferences of the next incomming messsage since their internal functionning uses an array of delays on wich the message pass and is read. And it can start having a new string incomming on that array while the first didn't disappear yet. By having 22 receivers, one is always hept clean (the enable function can stop signals from getting on the internal delay array).
Also there is a pseudo-processor. It's just a set of 5 logic blocks to swap the used strings during a transmission.
Protocol names :
Sender : H7.4-S1-2.2-N
Receiver : H7.4-R1-0-F2.1.0 (there is no upper limit for time between incomming strings)
After being send the 2 4-bits strings are saved and displayed on some sort of screen made of activation blocks for 4 sec, after that everything is being reseted.
A schematic of the following build will look like that :
A few things can be noted here.
First of all there are 2 receivers that are connected to the same antenna (white columns in the build). They swich once one has read something (if there 4 messages 2 receivers would still be sufficient) with their enable input function. The reason there is not only one receiver is to avoid interferences of the next incomming messsage since their internal functionning uses an array of delays on wich the message pass and is read. And it can start having a new string incomming on that array while the first didn't disappear yet. By having 22 receivers, one is always hept clean (the enable function can stop signals from getting on the internal delay array).
Also there is a pseudo-processor. It's just a set of 5 logic blocks to swap the used strings during a transmission.
Protocol names :
Sender : H7.4-S1-2.2-N
Receiver : H7.4-R1-0-F2.1.0 (there is no upper limit for time between incomming strings)
The last example shows ho to send 8 usable bits using 2 channels, so it would take as much time as sending 4 bits, but it requires having 2 antennas to connect together.
As before, the 2 messages, when received are displayed on the activation blocks screen before being erased after 4 sec.
A schematic of the following build will look like that :
Sender : H7.4-S2-1-N
Receiver : H7.4-R2-0-F1
As before, the 2 messages, when received are displayed on the activation blocks screen before being erased after 4 sec.
A schematic of the following build will look like that :
Sender : H7.4-S2-1-N
Receiver : H7.4-R2-0-F1
Overall, while basics builds are really simple, the building difficulty rise fast once you start combining functions but that's the price of modularity.
I will probably continue adding modules to the kit in the future, I will be posting about then in that thread. I'll also post here a full pratical example with a ship (the SFRU - Mako) and a station (WIP) where their interaction with radio is shown.
Also if you're interested I can create a small sub-kit of prefab radios made with these modules and that are plug and play.
Hope I have been clear enouth and thanks for reading!
I you have any questions feel free to post them here!
I will probably continue adding modules to the kit in the future, I will be posting about then in that thread. I'll also post here a full pratical example with a ship (the SFRU - Mako) and a station (WIP) where their interaction with radio is shown.
Also if you're interested I can create a small sub-kit of prefab radios made with these modules and that are plug and play.
Hope I have been clear enouth and thanks for reading!
I you have any questions feel free to post them here!
