got it. Thank you

@jens6151-0-1-1

Ah I see, I didn't realise it was a NuttX option. I was trying to figure out whether this support was a significant reason to use one of the listed chips over another option, which I'm not sure it is.

Thank you for your advice! I'll keep that battery voltage/capacity article in mind as well, it's very useful!

@jens6151-0-1-1 see farapi can get into deadlock when SMP is on.

@CamilaSouza I am currently running Win 10

@CamilaSouza I conclude that concurrent usage of network connections is no issue (at least not with the Spresense SDK.

I could resolve the disconnects of AWS IoT by switching to AWS IoT SDK which is integrated in NuttX. Paho does not seem to work well. I always get client errors without further reason in the AWS logs.

This issue can be closed.

@jens6151-0-1-1 Using 48 KHz without doing any sampling conversion works fine for me. I do not need to load any DSP and do not need ASMP.

@CamilaSouza I did a lot of research about this freezing issue I have.
I came to the conclusion that GNSS does not work with SMP. It causes freezes, crashes or might work. The behavior changes if you modify your code.

I can see that (likely) when receiving data from the GNSS CPU (1). Some random memory gets overwritten with ff. Depending on where this is either freeze, crash or normal behavior happens.

[CPU0] arm_hardfault: PANIC!!! Hard fault: 40000000 [CPU0] up_assert: Assertion failed CPU0 at file:armv7-m/arm_hardfault.c line: 135 task: gnss_receiver [CPU0] up_registerdump: R0: 000000ff 000000ff 00000000 deadbeef 000000ff 2d0378b0 00000000 2d03089c [CPU0] up_registerdump: R8: 00000000 00000000 00000000 00000000 0d013bd1 2d03ceb8 0d006413 0d0063d0 [CPU0] up_registerdump: xPSR: 61000000 BASEPRI: 00000080 CONTROL: 00000000 [CPU0] up_registerdump: EXC_RETURN: ffffffe9 [CPU0] up_dumpstate: sp: 2d02a618 [CPU0] up_dumpstate: IRQ stack: [CPU0] up_dumpstate: base: 2d029e80 [CPU0] up_dumpstate: size: 00000800 [CPU0] up_dumpstate: used: 000001b8

Could you please check?

tools/config.py examples/gnss examples/smp_asmp # or tools/config.py examples/gnss feature/smp # or tools/config.py examples/gnss feature/lte_stub_mbedtls feature/smp make tools/flash.sh -c /dev/ttyUSB0 nuttx.spk

Play a little with the configurations by modifying them.
This is not necessarily due to parallel running on the CPUs. Pinning all threads to CPU 0 also does not work.

+SMP_NCPUS=1

I even compiled https://github.com/ds-dyad/10n2-app/blob/master/sdk.config. This works. I cannot say what is the difference causing the issue or not. (I have LTE feature active?)
I also tried the GNSS sample some time ago with SMP. I remember it worked.
Like I said it seems random (but reproducible with the same build).

I already spend a lot of time. I do not know how to continue. I am about to close this investigation concluding GNSS @ SMP is not stable on Spresense.

Could you please check if there is anything I could do?

Btw SMP seems to not yet fully ready (It is considered stable, but there are open issues)

https://github.com/apache/nuttx/pull/8383 is not yet in the spresense sdk. and see here https://github.com/apache/nuttx/issues/3600
... nuttx/arch/arm/src/cxd56xx/cxd56_cpu1signal.c still uses shed_lock() and this is related with GNSS.

Hey @XY

After some investigation:

Through sends the sound from microphone directly to speaker. And speaker has just 2 channels: Left and Right.
So the behavior you are experiencing is the normal one. Ch A sends to left channel and Ch B sends it to right channel.

If you want to listen to the 4 channels there are two ways.
One is to save it in wav file. WAV format can support 4 channels in one file. 
The other is software mixer. 4 channels data is coming as Ch1, Ch2, Ch3, Ch4, Ch1, Ch2, Ch3, Ch4..... So you can make a kind of audio mixer to mix Ch1 and Ch2, Ch3 and Ch4, and then, output to speaker as Left Right channel.

@tamer_ae
This is the direct link
https://github.com/ds-dyad/10n2-app/blob/master/sdk.config

This is not my project, so I cannot give details.

I do not know if the speed plays an important role here. I added it to my code. (I interface LSM303)

Wire.setClock(400000); // 400KHz

On the first glance the code looks good.

I would try out one of the Arduino libraries like this https://github.com/adafruit/Adafruit_MPU6050. Just the given example to check if the hardware connections are good before writing own code.

@gyps
Also try to increase the upload speed.
There is a configuration ${config:spresense.serial.port}. I have no clue how to set it.
The alternative is hack it into the file spresense-sdk/spresense/sdk/tools/flash.sh

UART_BAUDRATE="230400"

Higher speeds are not successful.

Also do not forget the clean "make clean -j".

@CamilaSouza
Hi Camila, I still hope to get an answer for the previous question.

The mics are connected on the mic pins of the extension board (followed the instruction here: https://developer.sony.com/develop/spresense/tutorials-sample-projects/spresense-tutorials/using-multiple-microphone-inputs-with-spresense)

The earphone is connected to the headphone connector on the extension board (for audio output).

Since this project is for SNR measurement, I use the audio recorder mode. My question is: Can I generate an audio beep to earphone through headphone connector as an alarm? I do not know how to combine the audio recorder mode and the audio player mode together.

Thank you in advance for any help,

Best,

Larry

@dshilov-1-1 Thank you for your reply.
I only have the extension board. I thought that was a different sensing add-on as the accelerometer included in the EVK-701 is not BMI160.

I do have another IMU which I tried to use but I keep getting the failed to connect to I2c error. is there a way to check if the hardware is fine or not?
Many thanks!

Hi, @jens6151-0-1-1

Thank you for your feedback!
I'll share your feedback internally and investigate if there is a reason why it is done this way.

Hi @jens6151-0-1-1

Let me investigate this questions internally and get back to you as soon as possible.

@jp04 No I do not know the precission of the GNSS. I did not measure it.
So we need to believe the documentation. See

GNSS Performance GNSS Performance

If you can use QZSS-L1S then it says <2m 95% accuracy in Japan. Otherwise <7.8m in the city.

If I ever should do any measurements with I can post them. However sorry, there is currently no plan to do so.

Hi @jens6151-0-1-1

We have reproduced the issue, and it will be fixed in next SDK release 🙂

Thank you for your support in finding this issues so we can improve our SDK.