Digital ITC with FPGA

[Michael Lee]

I'm currently trying digital ITC. I move around quickly from idea to idea like a road runner. ("meet meet!")

The general idea is to receive 8 bits per second, with one parity bit. My field programmable gate array (FPGA) noise source yields 50 million random bits per second. 

Lets call the slow bits "group bits." 8 group bits per second. 8 group bits per "symbol". I decide on each group bit by summing 6,250,000 random bits. If its above the moving average, I assign a '1' , otherwise I assign a "0".

Parity means that the number of 1s per second/symbol should be even. If it isnt, then that's a bad symbol. Goal would be to have no bad symbols.

Symbols can be translated by 7-bit ASCII character set. Or we could reduce to a 5-bit letters only set.

Either way, the first, very simple question is how good can spirits maintain parity? Random chance says there would be 50% symbols rejected.

[Andres Ramos]

19 minutes ago, Michael Lee said:

I'm currently trying digital ITC. I move around quickly from idea to idea like a road runner. ("meet meet!")

The general idea is to receive 8 bits per second, with one parity bit. My field programmable gate array (FPGA) noise source yields 50 million random bits per second. 

Lets call the slow bits "group bits." 8 group bits per second. 8 group bits per "symbol". I decide on each group bit by summing 6,250,000 random bits. If its above the moving average, I assign a '1' , otherwise I assign a "0".

Parity means that the number of 1s per second/symbol should be even. If it isnt, then that's a bad symbol. Goal would be to have no bad symbols.

Symbols can be translated by 7-bit ASCII character set. Or we could reduce to a 5-bit letters only set.

Either way, the first, very simple question is how good can spirits maintain parity? Random chance says there would be 50% symbols rejected.

Hi Michael  Great you show us your work here in the forum!

I want to repeat what you said to see I got your points. You are working  with bytes encoding characters according to the 7-bjt ASCII character set. Every bit in these bytes is a product of summing a long sequence of 1s and 0s from a high speed bit stream and deciding which value outweighs the other. Ok so far

What I don't understand is why the you want to maintain bot parity in a byte. I remember parity bits to be important in a serial byte transfer acc. to the V.24 standard (if I remember correctly) but not in the ASCII encoding?

Nevertheless the idea is thrilling to have a spirit teletyper. One more question is coming up in mind while pondering your idea, can a spirit who wants to convey a message, manipulate 8 parallel running bitstreams simultaneously?

 

[Michael Lee]

Parity serves two purposes: reject symbols that have a bit error and measure the quality of the ITC signal. It's not meant to match any standards.

Yes, it is possible to have parallel bit streams. The sky is the limit. However, for now I'll be happy with telegraph speeds from the 1800s.

 

 

 

[Michael Lee]

Ok. For viewers tuned in at home. Here's the first result: For all symbols collected, ~55% parity correct. 50% is expected by chance. 

So it's something, but it's also bad enough that I'm not even ready to read the symbols. Maybe I'll be impressed with 70%?

I have several noise sources to try. Maybe one of them will make the cut?

Stay tuned.

Edit 1: Some other noise sources I've tried are at 47% correct parity. 55% is the max I've seen so far. I think this variation could easily chalked up to the algorithm I'm using to extract the bits, specifically how quickly I'm updating the mean , which is the dividing line between whether to assign a 0 or 1. Therefore, I would like to see at least 60% or greater to know we're going somewhere.

[Andres Ramos]

3 hours ago, Michael Lee said:

Parity serves two purposes: reject symbols that have a bit error and measure the quality of the ITC signal. It's not meant to match any standards.

Yes, it is possible to have parallel bit streams. The sky is the limit. However, for now I'll be happy with telegraph speeds from the 1800s.

 

 

 

Ok, so the question is if the spirits would act accordingly to your specification. Can we tell them how to do it?

[Michael Lee]

They can hear the tones being generated. High frequency for 1, low frequency for 0, and silence if the symbol doesn't pass the parity test.

I have it running, now. Unmonitored. But recording. They've been playing with my FPGA noise sources for months, and getting decent results with voice. So I imagine they know what's going on. Still, the limits of physics may prevent them from having sufficient control of the noise sources.

[Fernando Luis Cacciola Carballal]

Hi Machel,

Great work here!

For any digital ITC work I would like to separate the two main aspects: "transport" and "encoding"

Transport means the way in which the sequence of bits they intend to transmit is being effectively transmitted and received. That is where, for example, the extra parity bit comes into play. 

At this point is important to have in mind that a parity bit is just one of many "error detection codes", but there are others, and it might be interesting to know which byte-qualities we get with other error detection codes. These are all in the standard literature, but I can post one or two here in a comprehensive manner if you want.

There are also error correction codes. That is, with an additional level of redundancy, it is possible to not only detect but even correct "flip bits" (i.e. bits that are incorrectly received). I can also describe one here if you want.

Another thing regarding transport is the synchronicity. In a physical line communication, there is often a known and stable clock signal so we know how long is a bit. That is, the so-called bit rate. In our case, we don't really know that, and you are forced to pick an arbitrary rate (6250000 bits on the source stream). 
As we discussed before in another thread, they might not be able to stick to any rate at all, so, it would be interesting to try a design in which you use an "unbounded window" that is constantly  looking for a state-changes. That is, a design in which any bit can have any length whatsoever. As discussed before, this is possible with a 3-state machine.

The encoding aspect is what is the meaning of the bits sequence. They might not be encoding human natural text for instance.

I would like to make sure to keep this separated, because you might be getting all the right bits, yet they are not letter at all. We don't know that a priori. 

In this scenario, it would be interesting to feed the bit streams to a number of "discriminators", each trying to find for any meaningful signs within the data. Similar to the way a SETI explorer does, trying to find hidden signs in cosmic radiation (we can even copy some of these methods).

 

 

 

 

[Michael Lee]

So, I would say my experiment to allow spirits to preserve byte parity failed. I still think it is a good test, and now is arguably an experiment I will return to as I think of different noise sources to program on the FPGA.

I agree it's possible that spirits have trouble synchronizing with our time systems. I also think it's possible they can't see the "1's" and "0's" going through my chip. It's also possible they just aren't interested in this particular experiment.

Another possible problem is the algorithm I'm using to extract the bits: finding the mean, and then assigning bits by being above or below that mean. Perhaps, a bit should only be assigned when it is several standard deviations away from the mean. Otherwise, it might be assumed that no signal was sent.

A positive outcome from this experiment is I feel like I now have a convenient objective metric to evaluate noise sources. When they produce 8-bits, they should be able to ensure "parity", aka an even number of 1s and 0s. It's a relatively simple agreement between experimenters Here and There. I'm not asking for a particular language or response, simply a consistency check.

Edit #1: I added an example of what the FPGA sounds like and looks like as a spectrogram when it's making the bits. There's a low tone for a 0, high tone for a 1, and silence for a rejected byte. It has nothing to do with ITC, but I had to make this so I could communicate the FPGA's group bits with my PC. It's surprisingly difficult to get an FPGA to talk to a PC. I have a much better idea (logic analyzer) if I need it in the future, but this was a fast hack.

example_sound.mp3

[Keith J. Clark]

Cool clip. There may be Morse applications for this in the future. I listened for it but the first character was 6 symbols. 

Remind me to run this through the latest software techniques on my side sometime. 

Cool beans

[Andres Ramos]

So you let the FPGA communicate with the PC by sound? What a cool idea!

I see that based on this setup a direct interaction with the spirits could be possible. If you tell them they should produce 5 bytes without and then 3 bytes with parity and then this really happens, it will be a proof for spirit interaction.

[Michael Lee]

Andres, right! I'm asking them to do some simple math. No language encoding necessary.

[Fernando Luis Cacciola Carballal]

Hi Michael
As you said, there are many possible reason why this is not working, but I totally agree with the principle that this "flag" [to use the terminology that is used in communication theory] is the simplest information they can try to send in a way that we can objectively confirm. The agreement on parity check is granted (we all assume we can definitely align our intentions), so, for as long as we don't get that, something isn't working at this "transport layer"
So that is a great step forward!
 

[Andres Ramos]

You could start with a simple procedure. First let your circuit run and look for the chain with the maximum of bytes with parity and how often it shows up. Then advice the spirits by meditation every day to make the chain of consecutive bytes with parity as long as possible and see what happens.

[Michael Lee]

After a nice break and a little thought, I've decided on what to try next for this effort.

The idea I have is to assign three states to a signal: 0, 1, and X (undetermined).

For most of our audio ITC efforts, we use noise gates, or other threshold techniques (like spectral subtraction). Same here. To get assigned a '0' or '1' will require a certain amount of deviation from the mean. If the deviation is too small, we'll just assign X.

So let's say a byte shows up as 11X00001 , rather can call it a failed parity check (it should have even # of 1s), we'll just reject this byte and wait for the next byte. I sort of use the "anomalous value" approach in my ITC "soccer game" program, and it seems to help. 

The theory is that the signal-to-noise ratio is very low for ITC, at least with our current technologies. Thus, we need a lot of deviation from "normal" or "normality" to be sure we are getting an ITC signal. This doesn't mean that spirits can't send continuous streams of information, it's just that we're not entirely sure of their signal most of the time.

Now, the downside of this approach, is it will slow things, as many bytes will get rejected - perhaps up to 255 out of 256! But, we can ameliorate this issue somewhat by increasing our expected bit rate. Currently our bit rate is 1 bit per 1/8 second. But in the future, we can try speeding things up if we are successful with this "slow" test.

[Andres Ramos]

I think this is a good idea. We gain more certainty that the generated bytes are really the result of a pk effect and the spirits could use it to train their influence .