Download the program for the device via the Internet.

[gilanetugila]

Good afternoon! Thank you, but let's say the atmega 8 controller (16, 32) is enough to implement voice message transmission! I apologize for the delay, now I'm redoing the circuit for the current project, then I need to check the correctness of the connection and the transmission and reception of data over the uart bus. Unfortunately, this is not as fast as we would like.

[chipfryer27]

Hi

I have to ask, but as you have internet access at the location why can't they just call you on a phone (cell / landline)? Much easier than trying to create your own VOIP.

Alternatively, many of the GSM modules can be turned into "phones" with probably less hassle. In addition they give you Internet access too.

I think you may be straying away from what you initially want to do though.

Why not list your most important features, the "must haves", then list your "if possibles" too? I see no issues in getting your Mega to communicate over the internet but I predict difficulties in getting it to do VOIP all at the same time. I really don't see the need for it as there is an existing phone line at the premises.

Regards

[gilanetugila]

Good evening! I've soldered everything I need: indicator, controller, button, 3.3V power supply for the Wi-fi module, terminals-two identical boards. Now I'm trying to transfer data from one to another over the uart bus, but for some reason the communication quality is very poor-it reaches 25-35% correctly, the rest is either incorrect numbers, or the number is sent, but nothing changes on the receiving controller. I sent different numbers from 0 to 25, tried with byte and int types. I tried different speeds of 2400, 9600, 57600.At 2400 and 57600, the results were even worse. I watched the signals when they were sent on the oscilloscope, everything is fine there-they are sent. One of my friends says that it is necessary to clock from a quartz oscillator, but I use an internal oscillator. Is it really that critical?

As for the project itself, what do I need at a minimum: 1) transfer variables to a certain device on the controller, which will be written to memory and will be used from there for some time.2)data will be transmitted either from a controller connected to the esp8266 module (variables for several devices will be written to the controller memory) 3) use the Internet for transmission 4) use esp8266-01 type WI-FI modules for this purpose.

In principle, there used to be an idea to download data from the site, but this idea has its drawbacks-additional costs for creating and maintaining a web page, it is more difficult to implement.

[chipfryer27]

Hi

You will need to attach your charts for me to have a look.

Internal oscillator should work fine but not being very familiar with the ATMega I'm unsure if you will need a C-Block to configure. However if you create a one-second flash test this will help you establish if the chip is running at the correct speed.

Have a look at this post

https://www.flowcode.co.uk/forums/viewt ... 4&start=40

Here I use 2 x esp8266s to transmit / receive dummy data. Although the microcontroller is different to yours, the steps will be pretty much the same and hopefully will help.

Regards

[gilanetugila]

Good afternoon! The attached files contain programs for sending and receiving data over rs232 .An internal generator is used. Normally, 30-40% of the data comes in, in other cases either erroneous data, or it stands as if nothing is happening. I watched the data being sent by an oscilloscope -there are pulses when sending, but without decrypting the sent value of the number.

[chipfryer27]

Hi

Sorry to be brief, a little busy just now with things.

I have had a quick look at your charts and I think I can help you improve. I'll try and get back later tonight but if not then it may need to wait until the weekend.

Regards

[chipfryer27]

Hi

Sorry for late reply.

I'll reply further early in the week.

Regards

[gilanetugila]

Good evening! Today I connected 1.8432Mhz quartz and two 20 pf capacitors to the controller of the transmitter and receiver of uart bus signals. It got a little better to accept, but it's still bad: out of 25 numbers, as many as 6 numbers were incorrectly accepted!

[gilanetugila]

Good evening! I changed the programs a little-now data is also being sent via an interrupt. The results are slightly better: once I transmitted 25 numbers and there was 1 error, another time I transmitted 25 numbers and there were 6 errors. In the attached files, the voltage at the TX pin of the rs232 bus is without distortion.

[gilanetugila]

More signal graphs.

[gilanetugila]

More signal graphs.No special distortions were found.

[chipfryer27]

Hi

Interesting traces.

Sorry for not replying to things sooner, just been a bit busy. I should get back to you regarding things over the weekend.

Regards

[gilanetugila]

Good evening! Thank you for not forgetting about me.

[gilanetugila]

Good evening! I found one error where the data reception module has the parameter "timeout=a", but it should be "timeout=50...200", but this change did not help much. Then I tried the "circular buffer" option, the same without much success 5-8 errors. I tried sending the same number in a loop an odd number of times (3) after 1 second. When receiving, I received several data-they alternated on the display, one of them was definitely correct. But it's fine when you know what you're sending...

[chipfryer27]

Hi

Looking at your Send chart from above (in FC v8).

You seem to be using a 1.8432 MHz clock. This seems a bit low. Is there any specific reason you are using such a low crystal in your design?

In your chart you run the risk of holding your button pressed for too long, thereby sending more than one value as you have no indication it has been successfully read until after it has been sent. I assume your "loop two times" is to flash a led or give some other indication, but you have forgotten to include a delay between enabling C5 and disabling C5. You are using the software debounce feature of the component which generally speaking is fine however I've found that I sometimes need a bounce of 50mS if using cheap buttons.

Other than the above, your chart should pretty much do as you want in that it should on each press of the button send out an incrementing value which resets to zero upon exceeding 25.

Looking at your Get chart.

Same comment regarding clock speed as above.

In your Main loop you enable RXINT to call yor ISR (rs232). You don't need to have this in your loop as it only needs to be enabled once. I would move it to just before your Main loop.

Generally speaking any ISR should be as short as possible. Do only what you need then exit.

In your rs232 ISR you grab the incoming character and then loop two times toggling C5 as per your Send chart. Again though there is no delay between enabling and disabling C5. Personally I would not have this feature of your chart in the ISR. In your Main loop you could branch to toggle C5 if and only if your variable "a" has changed.

Once you exit your ISR and are back in your Main loop you convert the incoming value (a) to a String and display. However this will constantly display the last value received as variable "a" is never changed until you receive an incoming transmission. Nothing wrong with that if that is your intent.

Other than my comments above, you should be able to receive. Do remember though that if using breadboard the jumpers and connections can cause problems such as bouncing and false triggering too.

Hope this helps.

Regards

[gilanetugila]

Good afternoon! There is no particular reason why I chose a 1.8432 MHz quartz resonator - only a more accurate oscillation frequency. Which frequency should I choose to work with the uart bus?

I had different programs. I will send them in the attached files. The option when using a loop on C5 is just instead of a delay. In other versions of the programs, I refused to do this.

The Rx interrupt in different programs, I had it both in and out of the loop. I tried several different options yesterday. It seems to me that the option of using an interrupt in a loop gives better results than outside the loop. In the error cycle, somewhere 1-8, outside the error cycle from 8 to 18...But again, this is only for such a program design. If the design of the program is different and the results may be different.

As with the spi bus, I use the same boards, the same controllers and indicators. I use wires and soldering to connect the elements on the board and between them. I'm going to use the mock-up wires to connect the esp8266 modules, but they also have ends that are connected to my boards -soldering is used there.

[gilanetugila]

I will also attach a data reception file using a cyclic buffer and later today I will try to take out the interruption of data reception for the general cycle.

[gilanetugila]

Good afternoon! I found information that quartz 1.8432 MHz is very suitable for data transmission over the uart bus. This is due to the fact that when transmitting a signal, the frequency is divided by 16: 1843200/16= 115200, and to get a transmission rate of 9600, a WHOLE division coefficient of 12 is used. In addition, there is information on errors at the frequencies used.

[chipfryer27]

Hi

The speed is more than fast enough for 9600 Baud, my comment was really for anything else you may be doing that may benefit running a faster clock.


Latest send:

In Main loop I'm not sure why you have a 10mS after clearing display display and reading the button status. Similarly I'm not sure why you need the 500mS delay after you make your calculation. You then loop three times sending the value out on the UART with a one second interval so this gives plenty of time for you to release button / button to settle.

No reason I see as to why it shouldn't do as you want though.

Latest Get:

There is no reason at all to keep re-enabling the Interrupt (just as there is no need to keep (for example) reinitialising the display or any other component) so move it to before you loop. The ISR action itself manages everything associated with the Interrupt.

You really don't need a timeout of 200mS to receive your character (but it won't really be affecting much).

Again, no real reason as to why it shouldn't work.

Get using CB:

Again, move the interrupt to before Main Loop and other than a couple of delays I think unecessary there isn't anything to suggest you shouldn't receive. Your use of the CB is a good example of how to populate and retrieve.

If you have a USB-TTL Serial converter you can use that to help you faultfind / locate problems. Connect the Rx of your USB-TTL Serial converter to the Tx pin of your Send board. Using a Terminal program on your PC you will see what is being sent by your chip. If all good move the Rx to the Rx pin on your receive board and see what's happening there.

Regards

[gilanetugila]

Good evening! Unfortunately, I do not have that USB-TTL adapter, at first, when I just started checking the operation of the circuit, I used an oscilloscope, especially since one of my friends advised me to check the pulse fronts. I checked both the fronts and the pulses that come from the TX, all the pulses pass, I could not decipher them. But in each sending of 25 pulses, usually from 1 to 3, when nothing changes on the lcd1602 display, but on the oscilloscope it shows that other pulses are coming. In other words, the transmission of pulses is normal.

In the program, I have a delay after counting 500 ms, so that when pressing the button, only one pulse is guaranteed to be sent, and not several. If you put 50 or 100 instead of 500 ms, when you click on the button, the count will happen very quickly and chaos may occur when sending numbers.

When I found the error in the timeout, I used 200 ms from the beginning, and then tried for 50 ms. I didn't notice any special improvements.

Now I have tried to take out an interrupt per cycle, a timeout of 200 ms (although I have already tried this before). The reception got worse. So I got the following results: 1)the data sending program is standard (1 number each), reception is an interruption outside the cycle without using a cyclic buffer of 13-16 errors 2)the sending program when one number is sent 3 times in 1 second, reception as in (1) program 10-12 errors 3) the sending program as in (1), and reception using interrupts outside the loop and with a cyclic buffer of 16 errors.

[chipfryer27]

Hi

In the program, I have a delay after counting 500 ms, so that when pressing the button, only one pulse is guaranteed to be sent, and not several. If you put 50 or 100 instead of 500 ms, when you click on the button, the count will happen very quickly and chaos may occur when sending numbers.

Then you must have a very serious debounce problem or the button is sticking. Perhaps use your scope on the button?

Even if you remove your 500mS delay you still have a whopping three seconds where you loop whilst repeating your send before you sample the button again, so if you are still getting random transmissions you really need to check your physical circuit to see where the random transmissions are coming from.

Just a thought, are you sure you have the 1.8xxx MHz crystal connected and not accidentally mixed it up with an 8MHz or the like? That would make everything run over four times faster than expected.

I'll look at your latest charts later.

Regards

[chipfryer27]

Hi

Without knowing your scope setup / triggering etc all I can say is that some traces look close to a baud of 9600 but are too short to see any multiple transmissions.

If you send 0x55 /Dec 85 / ascii "U" that will give you a binary of 01010101 which should allow you to accurately measure bit periods which may help you establish the accuracy.

You say you get multiple transmissions if you omit the 500mS delay, but your charts don't suggest this is possible so you need to rule out anything physical. Perhaps connect one channel of your scope to your button and trigger on this, with the other capturing your Tx pin. Note the point is really to see button activity vs transmission, not capture bits so your time base should be long enough to capture Tx activity after the button is pressed.

Regards

[chipfryer27]

Hi

I took one of your send charts and modified it to work with some hardware I have. Changed chip too but essentially it is your chart (attached).

Send_Data.fcfx

(12.34 KiB) Downloaded 5 times

No issue at all when sending, all good.

3 x Tx.jpg (46.84 KiB) Viewed 381 times

Tx Zoom.jpg (45.94 KiB) Viewed 381 times

Note that the Tx is also exactly what the Rx is seeing too.

However I did see some strange behaviour in the Rx charts. I would on occasion get a random character displayed, but the analyser connected to the Rx pin proved the character was not sent by the Tx circuitry.

I'll have a further look when I next get some time.

Regards

[gilanetugila]

Good evening! As for the 500 ms delay, I will check again how the device functions in real life and take the signals with an oscilloscope. I just tried a bunch of different options, sometimes I didn't like what I saw on the lcd1602 screen. Then I changed the program, but the delay remained. Usually, in order to change the menu or values on the lcd screen or 7 segment indicators with a button, I use a delay from 200 ms to 2 s so that the values do not skip quickly, that's all. There is no sacred meaning in 500 ms just if you quickly skip the desired menu or value, then you will have to go back and type again.

I will definitely try your option of sending the number 0x55 . I will write the results and pictures from the oscilloscope screen a little later.

I really liked the screenshots with your signals, does it show in some kind of simulation program? I wrote to you a long time ago that I already had experience sending and receiving data over the rs232 bus, but then I only limited myself to the simulation program. Everything was fine there. But in the real scheme, not so much.

As for quartz resonators, I am sure exactly to the extent that one can believe what is written on the side of the resonator.

[gilanetugila]

Good evening! I am sending you photos of both boards with quartz resonators.