[Tim Gunn]

Hi John
What type a sensor is this?

The ST micro GPIO can source upto 25ma output but is not good at sinking current on the inputs.
http://www.st.com/en/microcontrollers/stm32f411re.html

[Tim Gunn]

Hi Gabriel

Please go to our Techical support Portal:
https://support.multitech.com

Once you register and create a ticket we can see about getting you converted back. If needed we can add someone from Actility to assist as well.

Regards

[Tim Gunn]

Gorkem

What is the RSSI value when it is working?

[Tim Gunn]

Hi Daniel,

we have new firmware releases for AEP Conduit (1.0.33) & mDot (0.1.2). They are both available from the .net site.

http://www.multitech.net/developer/software/aep/upgrading-the-aep-firmware/

Flashing mDot Firmware

If you upgrade to 1.0.33 AEP, you’ll need to start using the latest version of libmDot on mbed.

[Tim Gunn]

Hi Josh

We will post the information in the case Sean created on our support portal

[Tim Gunn]

JFFS2 generates messages, is there a problem?

JFFS2 adopts the philosophy of keeping the user completely appraised of what is going on. This can catch out the unwary novice. The following messages can be moved to a higher log level once you are sure that they are benign.

Empty flash at 0xXXXXXXXX ends at 0xXXXXXXXX
This message is generated if a block of data is partially written. It is generally not a sign of any problem.

Name CRC failed on node at 0x00b620c8: Read 0x640c8ca3, calculated 0x795111fe
or similar message about CRC failures. If you have ever done unclean reboots – this is harmless. This just means that the unclean reboot happened (1) during data write or write buffer sync or (2) while GC was working or (3) while the write-buffer contained some data and was not yet synced before the unclean reboot happened. In them first and the third cases, you just lose the very last data you have written, in the second case you lose nothing. The wrong nodes will eventually be recycled by Garbage Collector and the messages will go (but they may live quite long).

But this also may mean that data on your flash was corrupted for sum reasons. Unfortunately JFFS2 cannot distinguish between node corruptions cause by unclean reboots and by real media corruptions. But the latter case is very rare.

[Tim Gunn]

Hi Alan

You are correct on the pin out.

TXD_1 is the serial input
RXD_1 is the serial output
CTS_1 is the flow control output to indicate when the TXD_1 is ready or not ready to accept data. (Low active indicates ready)

The EVDDA pin is only for the Ethernet transformer and works with pins ERX+- and ETX+-. Cannot be used for anything other than Ethernet transformer connections.

No schematic is available for the OCG-E

Regards

-Tim

[Tim Gunn]

Hi Rick,

You can download the ITU spec from here:

http://www.itu.int/rec/T-REC-V.250/en

Regards

[Author]

Posts