Missing The Mark for Ending of a Measurement Loop

Hi,

A measurement loop should end with "*\n" , can you give me the script that is send to the device?

Regards,

Walter

Hello Walter@Palmsens.com 

Thank you for your response! Here is my script. I basically update certain values in the script because of that I use snprintf.

snprintf(Chrono_Amp, 200, "e\n"
							"var p\n"
							"var c\n"
							"set_pgstat_chan 0\n"
							"set_pgstat_mode 2\n"
							"set_range ba %d%c\n" // Added current range control
							"wait %d\n" // Added tequilibrium
						    "cell_on\n"
							"meas_loop_ca p c %d\m %d %d\n"
							"pck_start\n"
							"pck_add p\n"
							"pck_add c\n"
							"pck_end\n"
							"endloop\n"
							"cell_off\n"
							"\n\0",
							Current_range,
							Current_unit,
							tequil16,
							EdcChro,
							tintervalChro,
							trunChro);

Hello Walter@Palmsens.com 

I agree with you about losing data because when I check the raw data before parsing, it looks like that "e\nM0007\nPda8061B74u;ba8030F9Dn,12,28\n" I recognized that there should be one more digit as well after the last 8. Based on the document, it would be like that "...,288\n*\n\n". Is that correct? Other thing is that when I increase the interval time to 5 s and keep total run time in 10s, I got same problem.

Hi,

If a 10s runtime and a 5s interval time still caused the same issue, I would suggest looking at the communication implementation.

Are you using interrupt or polling ? Do you have a circular buffer? How big is the receiving buffer? Are you able to grab a complete output of the latest script , I expect only 2 packets followed by the "*\n"

Cheers,

Walter

Like this:

M0007
Pda807A1CAu;ba635FE86p,10,20A
Pda807A1CAu;ba635FE86p,10,20A
*

I set it in interrupt mode. The circular buffer is in DMA mode, so in my case there is no circular buffer. Receiving buffer size is 100 bytes. 

So I understood that you are using DMA in circular mode, am I correct?

And the DMA generates an interrupt if some threshold is exceeded? 

So when the data comes in how fast are you parsing the data so the buffer can be overwritten in the buffer?

Which STM32 do you use? 

Sorry for al these questions but I have to get a complete picture of this.

No worries, thank you for your quick response!

I use UART in interrupt mode, not DMA mode.

Actually, I didn't know answer of the question,"when the data comes in how fast are you parsing the data so the buffer can be overwritten in the buffer?". How can I measure the how fast parsing of data?

STM32F407IEH6

Ah okay so you get an interrupt every time you receive a character?

Exactly, for example here is my receive call back function,

UART3 is for emstatpico and STM32 communication; UART2 is for STM32 to PC communication.

Hi , 

For a number of reasons, I don't want to discuss, I am not allowed to go in depth regarding programming.

I can give you some tips though which I think will help:

• Keep the ISR (Callback) as small as possible, so I would suggest implementing a ringbuffer that is pushed in the callback and popped in the mainloop.
• Do al the parsing in the mainloop and not in the callback.
• Also retransmitting the characters to the other uart can also be performed in the mainloop.
• Be aware that HAL functions can be time consuming

I am convinced these will help.

Regards,

Walter

Hi Walter,

Thank you for your comments! I will try to implement your idea. I have one more question. There is /RST pin which is 5th one. Can set it SET in certain periods and send the MethodScript to the sensor for running it again? Do you think it works? Walter@Palmsens.com 

Thank you

Hi Walter,

Thank you for your comments! I will try to implement your idea. I have one more question. There is /RST pin which is 5th one. Can set it SET in certain periods and send the MethodScript to the sensor for running it again? Do you think it works? Walter@Palmsens.com 

Thank you

Hi,

There is a possibility to flash a Methodscript to the NVM (Non Volatile Memory)  and set a flag that the Emstat Pico will run the script every time the Pico starts-up.

So every time you activate the /RST line (make it low) the script will be executed.

In EmStat Pico communication protocol V1.3 (palmsens.com)

is described on $3.7 how to flash the MethodScript to the NVM

And how to set the Autorun flag  is described in $5.6

Another approach is to make an loop in the script that has the hibernate command in the loop. is this way the script will run every defined period you set in the hibernate command.

See: MethodSCRIPT communication protocol v1.3 (palmsens.com)

I hope this will help.

Regards,

Walter

Thank you for your suggestions! It looks like the 'hibernate' is an easy option. Is the correct notation to use hibernate like that?

char const * Chrono_Amp =
						  "e\n"
						  "var p\n"
						  "var c\n"
						  "hibernate 0x03i 60\n"
						  "set_pgstat_mode 2\n"
						  "cell_on\n"
						  // A DC potential of 100 mV (EdcChro) is applied. The current is measured every 100 ms (tintervalChro) for
						  // a total of 2 seconds (trunChro). This results in a total of 20 data points at a rate of 10 points per second.
						  "meas_loop_ca p c -300m 2 10\n"
		    			  "pck_start\n"
		                  "pck_add p\n"
		                  "pck_add c\n"
		                  "pck_end\n"
		                  "endloop\n"
		                  "on_finished:\n"
		                  "cell_off\n"
						  "\n";

Hi AE104,

This will hibernate once, before starting the measurement. Is this what you want? You may want to include a loop in the script to repeat the hibernate -> measure sequence.

Kind regards,
Hielke

Hi,

My thought was that whenever the scripts run at the sensor, the system went to hibernate. In the next run, I expected that it wakes up and starts again. With this way, I plan to avoid continuous measurements.

Thank you,

You will need to encapsulate your hibernate and measurement in a loop. I recommend using the wake pin to wake from hibernation (it is active low) and to disable the wakeup timer. The hibernate "wakeup source" argument should be 0x3 in this case.