Hello....The OmniVision OV48C is a 48MP picture sensor with enormous 1.2-micron pixel size. This makes it atypically huge as the various 48MP picture sensors have a 0.8-micron pixel size. The higher pixel size is on the grounds that the sensor is truly greater. It has a 1/1.3″ sensor size, while the IMX586 and the Samsung GM1/GM2 have a 1/2″ sensor size.
@TE-KarlKomierowski That would be awesome! Yes anything that you may have will be helpful. i have been trying to port over a driver i wrote using the AT-cmd interface and some parsing ect. But my main struggle is integrating into nutx of course..
I am just having trouble with getting the driver i made to function. my hope was i could see how the code you had used worked and maybe clue me in on my mistakes.
My primary issue is getting the serial pins to communicate with the ESP. no matter what i include from the nutx library i cannot get serial communication between the AT and the ESP.
I'v been using standard 115200 8 none 1 settings. And i've noticed the issue both on native MacOs (using screen) and with Ubunutu via Parallells (using minicom). I originally thought it was a parallels issue but it seems its "my mac". I'll see if I get different results on another machine with USB 3. If this has not been reported by anyone else on a recent USB 3 machine then I guess it's something local to my setup, or some weird incompatibity with the Mac USB devices. (I have experienced issues with USB 2 devices requiring firmware upgrades to work with USB 3).
You can capture 8 channels digital simultaneously at 19khz 24bit. But if you want to record the sounds, please watch the bus bandwidth to the storage. When you record 8 channels of 192khz 24bit, you need to have the bandwidth of 192kHz x 32bit x 8channels = 6.144 MBytes/sec to the storage. In many cases, the bandwidth of SD cards is not stable to keep the performance due to the mechanism of the file system. If you want to capture stable sounds, you need to measure the actual performance of the storage that you are using. Please check the throughput from microphones to your storage beforehand.
It depends on the system. If you will use the same characteristic of digital microphones, I believe it can keep the phase coherence.
Please see the connection of digital microphones and Spresense below:
As you see, Spresense provides the same clock to digital microphones. Please see the capture timing of microphones below:
The data at the same timing from microphones are serialized at the same time. It means if the outputs from the digital microphones are generated at the same time based on the clock provided from Spresense, it will keep the phase between the microphones.
I am trying to run the spresense_gsm_fona_tutorial on the spresense which is connected to a FONA module.
When I run the application it often getting into the "Failed to turn on GPRS" error. And then a subsequent "Couldn't initialize HTTP request!" error comes out and nothing works.
I am debugging the issue at the moment. I have noticed if I at this point run the FONAtest module and try turning on/off the gprs with 'G'/'g' command from the serial console and then run the spresense_gsm_fona_tutorial application again, it starts working. At this point the issue is bit symptomatic and trying to do a characterisation of the issue. I thought to share with you in case you have ever experienced something like this.
I have attached the log file. I have modified the below to incorporate the APN name and the dweet name as below in the code:
I looked into this and it sees you're right about the arduino library missing the absolute exposure time set function.
I have not found a project using manual exposure time but I looked into the Nuttx driver handling for the isx012 camera chip. Extracting information from the driver I added a function to the Camera driver: