There is no CSI data in the CSV file saved by the App

[whuryl]

Dear Steven, thank you for your work!

We can now get the CSI data from ESP32 and save them to the my-experiment-file.csv file of the computer, for example:

CSI_DATA,STA,74:05:A5:92:11:E1,-52,11,1,7,1,1,1,1,1,0,0,-89,1,6,1,6341572,0,114,0,0,6.71627,612,[114   -96 6 0 0 0 0 0 0 0 0 0 -5 -3 -8 2 -12 6 -16 9 -20 12 -23 12 -27 12 -28 10   -29 8 -28 6 -26 4 -23 2 -19 1 -15 1 -10 2 -6 3 -2 5 2 7 5 10 8 13 10 15 11 18   11 21 10 21 9 22 8 22 0 0 4 17 4 14 3 10 4 6 4 1 6 -3 8 -6 10 -9 13 -12 15   -13 17 -14 17 -14 18 -14 18 -12 17 -11 15 -10 12 -9 9 -9 5 -8 1 -8 -3 -9 -6   -10 -9 -11 -12 -13 -13 -14 -14 -15 0 0 0 0 0 0 0 0 0 0 ]

CSI_DATA,STA,74:05:A5:92:11:E1,-52,11,1,7,1,1,1,1,1,0,0,-89,1,6,1,7347868,0,114,0,0,7.72225,612,[114   -96 6 0 0 0 0 0 0 0 0 0 -31 0 -31 -2 -31 -4 -28 -6 -24 -6 -19 -4 -13 -3 -8 0   -3 4 0 8 3 12 5 16 6 18 7 21 6 23 6 24 5 24 4 24 3 23 2 20 2 16 1 12 2 7 3 3   5 -1 6 -6 0 0 11 -12 13 -14 14 -16 16 -16 16 -15 17 -15 16 -13 14 -12 12 -10   9 -8 5 -7 1 -6 -3 -5 -7 -5 -12 -5 -15 -6 -17 -6 -19 -7 -20 -7 -20 -7 -19 -7   -18 -7 -17 -6 -15 -4 -13 -2 -10 0 0 0 0 0 0 0 0 0 0 0 ]

However, when the ESP32 is connected to the mobile phone, there is no CSI data in the backup_xxx.csv file in the mobile phone. There are only four types of data: type, smartphone_id, timestamp, and current_action. For example:

type	smartphone_id	timestamp	current_action
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'sit'
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'transition'
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'stand'
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'transition'
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'sit'
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'transition'
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'stand'
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'transition'
'CURRENT_ACTION'	'4b5bb365bd3e491f'	1.63825E+12	'sit'

Now, I need to save the CSI data in the backup_xxx.csv file of the phone. What do I need to do?

The ESP32 CSI Tool Settings are as follows:

PROJECT_NAME: ACTIVE_STA
CONFIG_ESPTOOLPY_MONITOR_BAUD: 115200
CONFIG_ESP_CONSOLE_UART_BAUDRATE: 115200
IDF_VER: v4.3.1-dirty

WIFI_CHANNEL: 6
ESP_WIFI_SSID: WiFi110
ESP_WIFI_PASSWORD: WiFi666666
PACKET_RATE: 100
SHOULD_COLLECT_CSI: 1
SHOULD_COLLECT_ONLY_LLTF: 1
SEND_CSI_TO_SERIAL: 1
SEND_CSI_TO_SD: 0

The APP labeling method we select to TimerMainActivity in ./app/src/main/AndroidManifest.xml

        <activity android:name=".Experiments.TimerMainActivity">
<!--        <activity android:name=".Experiments.PressAndHoldMainActivity">-->
<!--        <activity android:name=".Experiments.ToggleMainActivity">-->
<!--        <activity android:name=".Experiments.ManualInputMainActivity">-->

Thanks again!

[StevenMHernandez]

Thanks for sharing the baud rate settings. I think you will need to set the baud rate the android app too.

To change the baud rate, you need to change this line: https://github.com/StevenMHernandez/Android-ESP32-CSI/blob/4dc455b12c8ba052752c0e689007444f10a26eb2/src/main/java/com/stevenmhernandez/esp32csiserial/UsbService.java#L44

You can find this file at the following path in the Android app ./ESP32CSISerial/src/main/java/com/stevenmhernandez/esp32csiserial/UsbService.java.

---

Question for you: Do you happen to have any android experience? If you do, I would like some advice.

I do not like that we need to manually alter this random line in a random file within the project to change the baud rate. The baud rate should be configurable more easily. (Can we use gradle to set this variable?)

Do you have any suggestions on how we can make it easier for users to set this baud rate config variable? If you can help think of any ideas, that would be very helpful. Thanks! :)

[touhiDroid]

@StevenMHernandez, about your question on adding the Gradle-variable:
We can do that by setting a variable in the gradle.properties file of the project as BaudRate=1552000
& then, it can be referenced inside the build.gradle file of the ESP32CSISerial module like the following snippet:

buildTypes {
        release {
            // set properties for the release-build ...
        }
        debug {
            // set properties for the debug-build ...
        }
        // set other build types (if any) ...

        // The following loop runs over all the build-types & inserts 'BaudRate' variable as static Java variable 'BAUD_RATE' into the generated 'BuildConfig' class of the package of 'ESP32CSISerial' module.
        buildTypes.each {
            // 'it' is the iterator over the build-types
            it.buildConfigField 'Integer', 'BAUD_RATE', BaudRate
        }
    }

If the project is built, the BAUD_RATE variable will be available to reference statically under BuildConfig class & we can update your coded Java constant as:
private static final int BAUD_RATE = BuildConfig.BAUD_RATE;

In this way, every time someone imports the module with the build.gradle written with the snippet above, s/he must have BaudRate constant specified inside the project's gradle.properties file.
Otherwise, Gradle sync. would throw an error after the import.

[StevenMHernandez]

@touhiDroid

For this project, there are actually three configuration options that a normal user would need to change:

1. Baud Rate (https://github.com/StevenMHernandez/Android-ESP32-CSI/blob/4dc455b12c8ba052752c0e689007444f10a26eb2/src/main/java/com/stevenmhernandez/esp32csiserial/UsbService.java#L44)
2. The selected Activity (

   Android-CSI-Labelling-App/app/src/main/AndroidManifest.xml

   Line 18 in e8b41c6

   <activity android:name=".Experiments.TimerMainActivity">

   )
3. Inside each activity there is a list of actions (https://github.com/StevenMHernandez/Android-CSI-Labelling-App/blob/master/app/src/main/java/com/stevenmhernandez/csi_labelling_app/Experiments/TimerMainActivity.java#L30)

Do you think it would be reasonable for this project to use your proposed approach for all three of these configuration options?

[touhiDroid]

Defining Gradle constant forces definition of the constant in the project (inside gradle.properties file) after importing the library & before building the project.
So, a rule of thumb is - if we need to force the developer to define the constant before using the library, then we should use Gradle constants.

Except for the Baud rate, the other 2 cases look like requiring the developer to specify as per the experiment.
I would prefer the activity selection (# 2) to be done from a menu - either at the start of the app (main-activity being something like MenuActivity) or from a drop-down at the status bar of each activity.

For the list of actions, the current setup looks fine to me, whereas the Gradle constant may need to be a JSON string & then unwrapped via the Java code & so looks like a messy workaround.

[StevenMHernandez]

I agree with the idea that being able to update this information would be useful from the UI rather than requiring the app to be rebuilt each time. I created a separate issue for adding this to the UI (#3), but I will likely not work on these tasks any time soon.

For now, I think it would still be good to bring all of these parameters into one easy to edit file.

You mentioned that gradle constants forces the user to define a parameter like BAUD_RATE. However you also mentioned that it would be a "messy workaround" to use Gradle constants for more complex parameters (like JSON arrays). I agree, it does seem a little messy.

We could update https://github.com/StevenMHernandez/Android-ESP32-CSI/blob/4dc455b12c8ba052752c0e689007444f10a26eb2/src/main/java/com/stevenmhernandez/esp32csiserial/UsbService.java#L44 to remove final from BAUD_RATE. Then we could add a new method public void setBaudRate(int newBaudRate) which allows us to more easily override the baud rate.

Alternatively we could set BAUD_RATE in the constructor for UsbService. Then when UsbService is instantiated within one of the Activities it will be correctly set.