Go Down

Topic: Max72xxPanel library (Read 2521 times) previous topic - next topic

Grumpy_Mike

You have nothing to stop the byte data being equal to the stop or start marker. So I would expect it to jam up at any speed.

nitinarora

You have nothing to stop the byte data being equal to the stop or start marker. So I would expect it to jam up at any speed.
Thanks for the quick reply Mike. I apologize if I did not understand your comment correctly. You are saying that if the data being sent by the processing serial at some point becomes equal to either the start/stop markers unintentionally then the sketch on the arduino would misinterpret this as the start or the end of the data stream?

A quick follow up on this though, if my above understanding is correct then the ASCII value of the start and the stop markers, 60 and 62 respectively would be the cause of the problem? The reason that I ask this is because the data that I send only ever has values between 0 - 16 from this line:


freq_array[j] = byte(random(0,17));


Again I really appreciate you taking the time to guide me.

Thanks
Nitin

Grumpy_Mike

Quote
he reason that I ask this is because the data that I send only ever has values between 0 - 16 from this line:
Sorry I missed that bit, that will prevent the data being confused with the the sart bits.

However note that in Processing the draw function is not quite like the loop function as it only gets called 25 times a second not as fast as possible like the loop function.

Try timing how long it takes your Arduino to read a frame. Sending data faster and it it working does not make sense unless it is taking too long to do the stuff on the Arduino side and the input buffer is overflowing.

nitinarora

However note that in Processing the draw function is not quite like the loop function as it only gets called 25 times a second not as fast as possible like the loop function.

Try timing how long it takes your Arduino to read a frame. Sending data faster and it it working does not make sense unless it is taking too long to do the stuff on the Arduino side and the input buffer is overflowing.
Ah! I did not know that about processing. Thanks for the pointer. I had a feeling that probably the Arduino is taking longer than the send speed to display the data. Incidentally in the processing sketch if I limit the values to 0 - 8, the sketch seems to run fine even at 115200.

I wish I had access to a scope or a logic analyzer to measure the timing. I am not sure if there is another approach to do this. Thanks for the help though I will try fiddling around with the baud rate and the delay till then.

Grumpy_Mike

Quote
Incidentally in the processing sketch if I limit the values to 0 - 8, the sketch seems to run fine even at 115200.
That points at the display part taking too long before the next lot of data comes along.

You can slow down the rate that Processing kicks out the data by using the frameRate call:-
https://processing.org/reference/frameRate_.html

Seems like the default rate is now 60 times a second not 25 like it used to be.

nitinarora

That points at the display part taking too long before the next lot of data comes along.

You can slow down the rate that Processing kicks out the data by using the frameRate call:-
https://processing.org/reference/frameRate_.html

Seems like the default rate is now 60 times a second not 25 like it used to be.
Awesome! Thanks Mike.

nitinarora

#21
Oct 13, 2017, 01:32 pm Last Edit: Oct 13, 2017, 01:39 pm by nitinarora
Finally with the fantastic help from Mike I have some semblance of a working prototype in place. Video at (apologies for the bad quality of the video):

https://youtu.be/vx5XEpgvAeY

Look forward to many such projects.

Thanks
Nitin

nitinarora

I have been it itching to do more on this, mainly because it looks so cool. I was thinking of expanding this both horizontally and vertically. So probably from 64 to 128 channels and then from 16 rows to 32 rows.

But given the timing issues this naturally can not be done with a single ATMEGA. I am curious to understand if it is possible to use the same HC-05 and have its output physically go to 2 separate stand alone arduinos and then use the appropriate values from the output in software.

So basically in the processing sketch send over 128 values and use one arduino to drive the first 64 columns and the second one to drive the next 64 but with a single blue tooth module.

Would certainly appreciate any thoughts.

Thanks
Nitin

Grumpy_Mike

Quote
I am curious to understand if it is possible to use the same HC-05 and have its output physically go to 2 separate stand alone arduinos
If the data is one way only then yes, but I think it would involve some sort of acknowledgment signal and you can't have two Arduinos doing that. It would be better to receive all the data with one Arduino and have it pass on half that to the other Arduino.

However, two Arduinos is seldom the answer. As you have a Max7219 in the mix that is doing the grunt work in regard to multiplexing so their is nothing much holding you back from using just one. Are you chaining the Max7219s?

nitinarora

Thanks for the reply Mike. The data would only be one way since the way this is currently set up, the arduino does not send back a confirmation to the processing sketch doing the FFT to indicate the completion of the display of a frame.

I did some initial test to try to send data from the HC 05 to the PC over the weekend but that did not work. I will probably need more time to set it up properly.

I am using Max7219 based modules, but the problem in its current shape and form was that when sending data at >38400 baud with no acknowledgement/delay between transmissions, the arduino just hangs after a while. This happens specifically when the values from the FFT are large (substantial number of values >8). If i limit the values being sent by processing to 0 - 8 things work just fine even without a delay. If the arduino is taking too long to load the values to the 7219 and the new data set arrives before that, I suppose at some point the sketch on the arduino would lock up.

I currently have a delay of 40 milliseconds before transmissions on the processing and that seems to work well. If i increase the delay the display looks "out of sync" with the music, hence the thought of multiple arduinos.

Thanks for all the guidance.

Go Up