Tom Hill
Forum Replies Created
-
AuthorPosts
-
July 15, 2020 at 2:13 am in reply to: Linker Errors when Compile custom firmware with latest MDOT Library. #30945Tom HillParticipant
Sorry false alarm, the linker error was because the main.cpp was missing :). My Bad!!!
Thanks,
YogeshTom HillParticipantHi Mike,
Thanks, I guess I will do that. I just imported the new library and based on the 2.0.17 revision, it seems like its using the mbed-os-5.4.2, however when building against my source code against the latest build of libmdot, I see some deprecated warnings as shown below. Hope this won’t cause any issues?
Warning: Function “mbed::Callback<R ()>::attach(R (*)()) [with R=void]” (declared at /extras/mbed-os.lib/platform/Callback.h:276) was declared “deprecated” in “libmDot-mbed5/MTS-Lora/vendor/multitech/MTS-Utils/MTSCircularBuffer.h”, Line: 102, Col: 17
Thanks,
YogeshTom HillParticipantThanks Mike, Is there a way to tell, this production version of the build encompasses until what version of the dev-libmdot. I am currently using the revision of dev-libmdot revision 75:60e021ba and mbed-os 5.2.2
Thanks,
YogeshTom HillParticipantIs this the case for the mdot as well or something that is specific to xdot?
Thanks,
YogeshTom HillParticipantAny inputs on this topic multitech team? Would help our planning on our go live dates better.
Thanks,
YogeshTom HillParticipantThanks Peter, that is exactly what I am doing, when the cell connection is down, I backup the data I am sending via the http request node, so when it is back up and I can send all the packets that were missed out from being transmitted. However I am not sure how I would reset the PPP link from node-red and I don’t do that currently.
So it seems like the keep alive feature seems to be OOB feature that I could use to reset the PPP link. Should I be using the defaults for the settings? I see that I could hit a public portal such as google.com as you suggested earlier, how often does it ping?
Thanks,
YogeshTom HillParticipantHi Peter,
Enabling the keep alive on the cellular connection, does it have any performance impact, or is it just to ensure the cellular connection is kept alive? I use http request node in my node-red flows extensively and so I check if the PPP connection is up using the internal web api provided by multitech using the URL http://127.0.0.1/api/ppp and look at the JSON result if the PPP link is up or down and I do this every 10 minutes.
However if enabling the keep alive in the cellular configuration tab is a better way to check this, I would rather use that? Do you have any suggestions?
Thanks,
YogeshTom HillParticipantHi Jeff,
Thanks for taking the time to respond.
Ideally I would like to determine the status of the two nodes from my node-red flow and if for some reason the mtac-lora card is down or unable to transmit packets, I would like the upstream connections to know of status of mtac lora card, so that there are no downlink messages sent from our upstream systems, so they don’t pile up messages in the conduit.
As far as my 3rd question, was if I can’t determine the mtac card status from my node-red flow, I was just going to see if I could subscribe to the LORA MQTT broker messages, But was unsure how best to achieve this? I did see this MQTT LORA URL. But haven’t used MQTT broker ever in node-red flows.
Thanks,
YogeshTom HillParticipantAny thoughts on how best I can achieve this? It is important to determine the status of the lora uplink and downlink status as that would allow us to control downlink packets from queuing up at the conduit and also report the status of the mtac card to upstream systems.
Thanks,
YogeshFebruary 18, 2017 at 12:23 am in reply to: Releasing receive buffer memory on Lora Radio event. #17346Tom HillParticipantThanks Mike for confirming. That helps a lot, I guess I didn’t notice the buffer on the mDotEvent object.
Thanks,
YogeshTom HillParticipantHi Mark,
Are you using mbed os5 I2C api’s in mdot, and was that causing the memory leak? If so can you share some details regarding that? As I am planning to use the I2C as well, where the MDot behaves as the I2C Slave.
Thanks,
YogeshTom HillParticipantHi Leon,
Sorry I got a bit side tracked and was facing issues with I2C even at 400khz. However it is working now. For now we should be able to make do with 400khz speed. However my client was looking to gather all the information incase we need to use 1mhz speed, so when designing our final board we will have no surprises.
Thanks,
YogeshTom HillParticipantIs there a way to view this log from the conduit web admin or would i need to SSH into the conduit?
Thanks,
YogeshTom HillParticipantHi Mike,
Just a follow up question. So based on the mdot page on the mbed website, the main thread has a stack size of 4kb.
1) Can this be increased to levels in mbed os 2? I am assuming the stack size in mbed os2 was higher?
2) What was the stack size of the main thread in Mbed os2?
3) Any global objects would be allocated on the main thread stack right? I am wondering if because of this the stack is overflowing on the main thread?Thanks,
YogeshTom HillParticipantThanks Leon for your input. I am a little confused, why would I need to reach out to ST’s sales rep? Shouldn’t I be working with Multitech’s sales rep? Since we purchased the MDot product from Multitech?
Thanks,
YogeshTom HillParticipantThanks Mike :). Not sure what I was thinking, Yeah that would definitely cause an overflow.
Thanks,
YogeshTom HillParticipantThanks Mike. I did try to increase the stack size of the child thread to 4k as suggested on the mdot page on the mbed web site and I got an RTX error code: 0x00000001 and I think this supposed to be stack overflow error. So on the MDot can I not allocate more stack space for a new thread I create? Btw this is the first thing I do in the main.cpp file as shown below.
int main() { //serial debug Serial pc(USBTX, USBRX); pc.baud(19200); // create a 4kB stack for the spi thread uint8_t th_stack[4096]; // create the thread with custom stack Thread tProcessSPIMessages(osPriorityNormal, sizeof(th_stack), th_stack); OSPISlave oSPISlave(spiSlave, pc, eventQueue); oSPISlave.Initialize(); //start the SPI processing.... tProcessSPIMessages.start(callback(&oSPISlave, &OSPISlave ::processSPIMessages)); eventQueue.dispatch_forever(); }
Thanks,
YogeshTom HillParticipantHi Mike,
I have not changed anything except for the fact the method was called directly by the main thread and now the same method is called when the thead.start method is called. I will see if I can get GDB to work on my windows 10 machine, I have had little luck setting this up in the past.
So when you say that MDot uses stand mbed 5 stack sizes, that would mean the stack sizes have reduced for the main thread and the child thread.
Thanks,
YogeshTom HillParticipantHi Mike,
Thanks for taking the time to respond. However I think I have the hang resolved for now, however it is not clear to me why it resolves it, may be you may have better insight to why its working.
If I run the SPI communication on the main thread, within a few deep sleep cycles, the mdot hangs on an SPI call, and I have turned on the logging level to the highest, which is TRACE_LEVEL and nothing is written out to the debug o/p.
So I ran the SPI calls from a thread spawned during startup and infact the deep sleep is called within the thread as well and now it no longer hangs. The priority of this thread is the default which is Normal. So not sure why this works, but not on the main thread. Also other thing I noticed while making SPI calls, I can’t seem to use any of the logging API’s or printf statements that would end up hanging the MDot as well. So I had to store the debug values and once I was done with the SPI transactions, I then write out all the debug o/p.
Also regarding the default stack size, the mdot page on the mbed site has a clear warning clearly called out. It seems like it is an mbed 5 change. Does this not apply for the MDot?
Thanks,
YogeshTom HillParticipantThanks Leon for your response. I have two mDots and one of them brings up this error when I power on the mdot. Both of them are running the custom application I have built. The error doesn’t show up when my application is running. just at the start up.
Thanks,
YogeshDecember 19, 2016 at 5:43 pm in reply to: Source code for the classes under the Utils folder for the libmdot. #16118Tom HillParticipantThanks Mike for pointing me to the source code. When you say older version as in not the current code used by the libmdot5 source?
Thanks,
YogeshTom HillParticipantThanks Jason for the link check explanation. Are there a performance concerns at the gateway and/or mdot end if every packet received is to be acked and when acks are enabled at the lora output node as well? Also does it effect the receive window if the ack is not received?
I am just trying to understand if we can do without using Acks and would it be a safe bet to just use link checks to verify the network health.
Thanks,
YogeshTom HillParticipantThanks Leon for taking the time to respond.
November 30, 2016 at 12:20 pm in reply to: What version of libmdot, mbed rtos, mbed should be used. #15733Tom HillParticipantThanks Leon, we will be testing with the dev build going forward, and hopefully the production version would be out eventually by the time we decide to lock the firmware. Thanks for calling out the version of libmdot to use and Yes we would like to use the PVD feature.
Thanks,
YogeshNovember 29, 2016 at 6:47 pm in reply to: What version of libmdot, mbed rtos, mbed should be used. #15717Tom HillParticipantThanks Leon, I was hoping that we could test with the PVD support at the earliest with the production build of mdot as the production build would be a more stable build. I will see if we can work with the dev build for now, but we are planning to lock our firmware release as well early Q1 of 2017.
Thanks,
YogeshTom HillParticipantThanks Mike for your response.
November 22, 2016 at 8:21 pm in reply to: What version of libmdot, mbed rtos, mbed should be used. #15614Tom HillParticipantHi Leon,
Thanks for taking the time to clarify regarding PVD functionality in the mdot. Is there any estimate as to when this will be rolled into the production version of the libmdot?
Thanks,
YogeshNovember 21, 2016 at 6:35 pm in reply to: What version of libmdot, mbed rtos, mbed should be used. #15596Tom HillParticipantThanks Leon.
I just needed to clarify one of your comments on the PVD enhancement. Can you elaborate on that? We are going to be eventually going to be running on a battery in the field. Also is this enhancement only currently available on the dev build or in the current production version of the build as well?
Also is this enhancement more MBED OS related, i.e. it is available on MBED OS5 and above?
Thanks,
YogeshTom HillParticipantThanks Mike for your response. What version of mbed rtos and mbed lib should I be using with the latest version of libmdot for mbed os 2. Also is there any enhancements with libmdot mbedos 5 that is not in current libmdot. I am trying to make a decision to upgrade to mbed os5.
Thanks,
YogeshTom HillParticipantHi Mike,
I was looking to upgrade to mbed5, however there was quite a difference in the deep sleep mode and sleep mode in mbed2. So are you saying that this gap has been closed in mbed5? Also the customer frustrations you mentioned with deep sleep mode, does that apply for mbed 2 as well? We picked deep sleep mode primarily because of the lower current consumption in mbed 2.
Thanks,
Yogesh -
AuthorPosts