[Antonio Muñoz]

Hi Jason, I know how to do it. I have created a script that I run from node red with the following line:

echo -e “mypassword \ nmypassword” | passwd root
This way when I want to log in with winscp, I can do it as root.

Cheers

[Antonio Muñoz]

Hi Jason. Thanks for your answer.
Currently I have another problem that I do not know how to solve. To access with winscp I must first access with a telnet session and configure a password for root (“sudo passwd root”). This way I can access all folders with winscp. However this is not permanent, when I restart the conduit, I have to do the same operation to be able to access with winscp. Is there a solution to make the root password permanent?
Thanks again and best regards.

[Antonio Muñoz]

I have tested it and it works fine.
There is a document where these details are described, to be able to consult it in the future without having to ask the forums.
Thank you very much again.

[Antonio Muñoz]

Hello Jason again.
Regarding the subject of this post, I am having problems with the new firmware version AEP 5.2.1.
Specifically, I do the same procedure as with previous versions (1.6.4) to transmit packets to a large number of nodes simultaneously. But with this firmware version the packets are not transmitted. Do you know what the reason may be?

Thank you so much and Happy New Year.

• This reply was modified 3 years, 4 months ago by Antonio Muñoz.

[Antonio Muñoz]

this is my config

{
“__v” : 1,
“addressRange” : {
“end” : “FF:FF:FF:FE”,
“start” : “00:00:00:01”
},
“backupInterval” : 3600,
“db” : “/var/config/lora/lora-network-server.db”,
“license” : {
“hasFile” : false,
“isValid” : false,
“maxDevices” : 2000,
“maxGateways” : 10,
“maxKeys” : 2000,
“type” : 0
},
“log” : {
“console” : false,
“level” : 30,
“path” : “/var/log/lora-network-server.log”,
“syslog” : true
},
“lora” : {
“ADRAckDelay” : null,
“ADRAckLimit” : null,
“ADRStep” : 30,
“aesKey” : “ABCDEF0123456789ABCDEF0123456789”,
“antennaGain” : 3,
“beaconDatarate” : 3,
“beaconFreqHop” : true,
“beaconFrequency” : 869525000,
“beaconInfoDesc” : 0,
“beaconInterval” : 0,
“beaconLatitude” : 0,
“beaconLongitude” : 0,
“beaconPower” : 27,
“calAD9361” : 77,
“calTempRoom” : 22,
“channelMask” : “”,
“channelPlan” : “EU868”,
“classCAckTimeout” : 5000,
“deviceQueueSize” : 16,
“diversity” : false,
“dspStatInterval” : 10,
“dutyCyclePeriod” : 60,
“dwelltimeDown” : 0,
“dwelltimeUp” : 0,
“enableStrictCounterValidation” : true,
“enabled” : true,
“eui_1” : “00:80:00:00:A0:00:30:E2”,
“frequencyAS” : 922600000,
“frequencyAS2” : 922600000,
“frequencyBand” : “EU868”,
“frequencyBand2” : 0,
“frequencyEU” : 864500000,
“frequencyEU2” : 867500000,
“frequencyIN” : 866385000,
“frequencyIN2” : 866385000,
“frequencyISM2400” : 2403000000,
“frequencyISM2400_2” : 2425000000,
“frequencyISM2400_3” : 2479000000,
“frequencyKR” : 922900000,
“frequencyKR2” : 922900000,
“frequencyRU” : 0,
“frequencyRU2” : 0,
“frequencySubBand” : 1,
“frequencySubBand2” : 1,
“fskSYNC” : “C194C1”,
“ftsMatchCRCError” : false,
“ftsVersion” : 1,
“gpsReceiver” : true,
“joinByteOrder” : “LSB”,
“joinDelay” : 5,
“lbtEnabled” : false,
“lbtRssiOffset” : -4,
“lbtRssiTarget” : null,
“lbtScanTime” : 5000,
“maxDatarate” : 3,
“maxDatarateEU” : 5,
“maxDatarateUS” : 4,
“maxEIRP” : 20,
“maxTxPower” : 0,
“minDatarate” : 0,
“minDatarateEU” : 0,
“minDatarateUS” : 0,
“nbDSP” : 1,
“netID” : “000000”,
“networkLeadTime” : 500,
“packetForwarderConfig” : “”,
“packetForwarderConfig2” : “”,
“packetForwarderMode” : false,
“pingSlotDatarate” : 3,
“pingSlotFreqHop” : true,
“pingSlotFrequency” : 869525000,
“reducedPacketUpdates” : false,
“rx1DatarateOffset” : 0,
“rx1Delay” : 3,
“rx2Datarate” : 0,
“rx2Frequency” : 869525000,
“skipPacketForwarderFieldCheck” : false,
“spi_device” : “/dev/spidev0.0”,
“sxOffset” : -162
},
“mqtt” : {
“enabled” : true,
“host” : “127.0.0.1”,
“password” : “”,
“port” : 1883,
“username” : “”
},
“mtsLic” : “”,
“network” : {
“baseKey” : “”,
“defaultProfile” : “DEFAULT-CLASS-C”,
“eui” : “544c4b4553545200”,
“joinServer” : “https://join.devicehq.com/api/m1/joinreq”,
“key” : “544c4b5f41455354524144415f303030”,
“leasetime” : 0,
“lensCheckinInterval” : 3600,
“lensDeviceHQ” : true,
“lensEnabled” : false,
“lensGatewayStats” : true,
“lensLocalJoinMetadata” : true,
“lensNetworkStats” : true,
“lensPacketMetadata” : true,
“lensPacketPayloadData” : false,
“lensServer” : “https://lens.devicehq.com/api/”,
“localJoinServerEnabled” : true,
“name” : “”,
“passphrase” : “”,
“public” : 1,
“salt” : “”,
“vendorId” : “008000”
},
“packetForwarder” : {
“aesKey” : “ABCDEF0123456789ABCDEF0123456789”,
“antennaGain” : 3,
“autoquitThreshold” : 60,
“beaconDatarate” : 3,
“beaconFreqHop” : true,
“beaconFrequency” : 923300000,
“beaconInfoDesc” : 0,
“beaconInterval” : 0,
“beaconLatitude” : 0,
“beaconLongitude” : 0,
“beaconPower” : 27,
“calAD9361” : 77,
“calTempRoom” : 22,
“channelPlan” : “US915”,
“diversity” : false,
“downstreamPort” : 1782,
“dspStatInterval” : 10,
“frequencyAS” : 922600000,
“frequencyAS2” : 922600000,
“frequencyEU” : 867500000,
“frequencyEU2” : 867500000,
“frequencyIN” : 866385000,
“frequencyIN2” : 866385000,
“frequencyISM2400” : 2403000000,
“frequencyISM2400_2” : 2425000000,
“frequencyISM2400_3” : 2479000000,
“frequencyKR” : 922900000,
“frequencyKR2” : 922900000,
“frequencyRU” : 0,
“frequencyRU2” : 0,
“frequencySubBand” : 1,
“frequencySubBand2” : 1,
“fskSYNC” : “C194C1”,
“ftsMatchCRCError” : false,
“ftsVersion” : 1,
“fwdCrcDisabled” : false,
“fwdCrcError” : true,
“fwdCrcValid” : true,
“gpsReceiver” : true,
“gwID” : “00800000A00030E2”,
“gwID2” : “0000000000000000”,
“gwSource” : 0,
“keepAliveInterval” : 10,
“lbtDefaultChannels” : true,
“lbtEnabled” : false,
“lbtFrequency0” : 923000000,
“lbtFrequency1” : 923200000,
“lbtFrequency2” : 923400000,
“lbtFrequency3” : 923800000,
“lbtFrequency4” : 924000000,
“lbtFrequency5” : 924200000,
“lbtFrequency6” : 924400000,
“lbtFrequency7” : 924600000,
“lbtRssiOffset” : -4,
“lbtRssiTarget” : -80,
“lbtScanTime” : 5000,
“manualMode” : false,
“nbDSP” : 1,
“path” : “/opt/lora/lora_pkt_fwd”,
“pathGeo” : “/opt/lora/pkt_forwarder”,
“public” : true,
“pushTimeout” : 100,
“serverAddress” : “127.0.0.1”,
“statInterval” : 20,
“sxOffset” : -162,
“upstreamPort” : 1780
},
“packetForwarders” : [
{
“channels” : [
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 868100000
},
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 868300000
},
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 868500000
},
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 864100000
},
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 864300000
},
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 864500000
},
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 864700000
},
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 864900000
},
{
“bandwidth” : 250000,
“enabled” : true,
“frequency” : 868300000,
“spread_factor” : 7
},
{
“bandwidth” : 125000,
“enabled” : true,
“frequency” : 868800000,
“spread_factor” : “FSK”
}
]
}
],
“spectralScan” : {
“bandwidth” : 200,
“duration” : 60,
“enabled” : false,
“floor” : -120,
“imme” : false,
“interval” : 1,
“limit” : 0,
“offset” : 0,
“ranges” : [
{
“start” : 902100000,
“stop” : 903900000
},
{
“start” : 923000000,
“stop” : 928000000
}
],
“samples” : 10000,
“startAt” : “09:00:00”,
“step” : 200000,
“stopCriteria” : 0
},
“test” : {
“disableDutyCycle” : false,
“disableGPS” : false,
“disableRxJoin1” : false,
“disableRxJoin2” : false,
“disableRxWindow1” : false,
“disableRxWindow2” : false
},
“trafficManager” : {
“dev_eui_filters” : [],
“enabled” : false,
“join_eui_filters” : [],
“updated_at” : null
},
“trimInterval” : 600,
“trimRows” : 100,
“udp” : {
“allowPublic” : true,
“appPortDown” : 1786,
“appPortUp” : 1784,
“downstreamPort” : 1782,
“lensPort” : 1790,
“upstreamPort” : 1780
},
“whitelist” : {
“devices” : [],
“enabled” : true,
“maxSize” : 2000
}
}

But when I transmit a packet, it doesn’t come out. It is exactly the same as if the devices were in class A, but they are in class C.

admin@mtcdt:~$ lora-query -n
Dev Addr Dev EUI Class Joined Seq Num Up Down 1st 2nd Ping Dropped RSSI min max avg SNR min max avg PER%
01:32:00:f9 01-23-a3-0b-00-e8-c3-64 C 2020-06-14T17:17:51Z 0 7 6 2 2 0 0 -25 -21 -23 7.5 11.5 9.5 58.82
11:11:11:11 00-11-22-33-44-55-66-77 C 2020-06-14T17:10:54Z 1 0 6 0 0 0 0 0 0 0 0 0 0 0
admin@mtcdt:~$

[Antonio Muñoz]

Hi Jason.
I tell you my problem.
I have a model MTCDT-H5 conduit in which I installed version 5.2.1, but I had a problem that I do not know how to solve, and that is that class C does not work for me, when I send a package, it stays in the conduit and does not comes out until the device does not contact the conduit,
After reviewing everything I have not managed to solve it, so I opted to go back to version 1.6.4, but when I tried it, it told me that it was an incompatible version, so I decided to do a factory reset by pressing the reset button for more than 30 seconds .
After doing this, when the conduit starts, the PWR and LS LEDs stay on solid, and the STATUS LED blinks. If I connect a USB on the back or front it asks me for a username and password, but I can’t enter admin / admin or the password that I had previously, it gives me an error in all cases.
I don’t know what to do to get the conduit back. It cannot be accessed from the network either.
thanks

[Antonio Muñoz]

The status led is blinking all time. and i can not acces from ethernet.

[Antonio Muñoz]

I’m going to study the information you give me. I have to analyze what happened on the device.
Thanks again.

[Antonio Muñoz]

Hi.
The device is RN2483.
You can receive many packages before this happens. It is sporadic. I have the counter disabled (“enableStrictCounterValidation”: false).
because the packets are sent without confirmation, one or more can be lost and the counters do not match. This is a security measure that in my opinion gives more problems than it solves.
If I have enableStrictCounterValidation = false, why does not it pass the packets?
thanks

[Antonio Muñoz]

Hi
The device is OTAA joined.
Normally paketes are received well.
But when this happens, the only solution is to make another Join OTAA. But the node does not know it.
I have version 1.4.16.
I would like to know what is the reason that this problem occurs and how to solve it.

Thanks again.

[Antonio Muñoz]

After a time without transmitting any message, I have tried again and the conduit has sent one by one all the messages that had had to send previously.
I do not understand why the messages did not come out.

[Antonio Muñoz]

Hello again.
Now I have a similar problem and when I try to transmit a data packet to a specific node, the packet is received by the lora-network-server, but it does not progress, it’s like the problem I had yesterday with the node created for multicast, I have tried with the previous solution:

lora-query -x device update <dev_eui> ulc 1

but the message has not progressed yet.
It only happens with a certain node.
This is what I see in the lora-network-server.log

8:48:35:646|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|DOWNLINK|Queue {“data”:”IFJTU0k6LTkwICBTTlI6IDkuOCAgQ0g6IDQgEA==”,”ack”:false,”port”:81}
8:48:35:679|WARNING| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE|Created downlink record ID:295
8:48:35:680|INFO| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE-TX|DATA SIZE: 28
8:48:38:726|TRACE| TX-ACK|127.0.0.1:56524 4 bytes 01c23104
8:48:38:726|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:56524
8:48:41:917|TRACE| TX-ACK|127.0.0.1:35478 4 bytes 01d95501
8:48:41:918|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PUSH-DATA|127.0.0.1:35478
8:48:41:919|INFO| GW:00-80-00-00-00-00-aa-85|FRAME-RX|Parsing 1 packets
8:48:41:919|WARNING| GW:00-80-00-00-00-00-aa-85|FRAME-RX|CRC-ERROR

8:54:21:386|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|DOWNLINK|Queue {“data”:”IFJTU0k6LTkwICBTTlI6IDkuOCAgQ0g6IDQgEA==”,”ack”:false,”port”:81}
8:54:21:435|WARNING| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE|Created downlink record ID:296
8:54:21:436|INFO| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE-TX|DATA SIZE: 28
8:54:25:526|TRACE| TX-ACK|127.0.0.1:56524 4 bytes 0104f604
8:54:25:526|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:56524

8:55:35:513|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|DOWNLINK|Queue {“data”:”IFJTU0k6LTkwICBTTlI6IDkuOCAgQ0g6IDQgEA==”,”ack”:false,”port”:81}
8:55:35:533|WARNING| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE|Created downlink record ID:297
8:55:35:545|INFO| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE-TX|DATA SIZE: 28
8:55:36:727|TRACE| TX-ACK|127.0.0.1:56524 4 bytes 01483c04
8:55:36:728|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:56524

I tried to make a new login ota, but it has not helped.
What is the solution ?

Thanks.

[Antonio Muñoz]

Hi Jason.
I have tried and it works perfectly.
I already receive the data in the multicast motes in class C.

Thanks again.

• This reply was modified 6 years ago by Antonio Muñoz.

[Antonio Muñoz]

Thank you very much Jason again
I will try

Regards

[Antonio Muñoz]

Hi Jason.
I have created a new node:

lora-query -x device add ‘{“deveui”:”00-11-22-33-44-55-66-77″,”class”:”C”}’

lora-query -x session add ‘{“deveui”:”00-11-22-33-44-55-66-77″,”dev_addr”:”11111111″,”appeui”:”22-22-22-22-22-22-22-22″,”joineui”:”00-11-22-33-44-55-66-77″,”net_id”:”008000″,”app_senc_key”:”00112233445566778899aabbccddeeff”,”fnwk_sint_key”:”00112233445566778899aabbccddeeff”}’

After I transmit a data packet to an existing node, it is transmitted correctly.

But when I try to transmit to the new created node, the message is not transmitted
I show you the lora-network-server.log of both messages

Good message:

10:33:19:436|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|DOWNLINK|Queue {“data”:”IFJTU0k6LTgwICBTTlI6IDkuMiAgQ0g6IDUgBQ==”,”ack”:false,”port”:81}
10:33:19:441|WARNING| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE|Created downlink record ID:66
10:33:19:453|INFO| ED:00-04-a3-0b-00-1e-a5-a0|QUEUE-TX|DATA SIZE: 28
10:33:19:463|DEBUG| Device::ScheduleSendApplication Class: 2
10:33:19:463|DEBUG| getTimeOnAirMs SF: 12 BW: 125 PL: 8 SZ: 28 TOA: 1482
10:33:19:464|TRACE| Schedule DC band: 2 available: 360000 duration: 1532 freq: 869525000
10:33:19:464|DEBUG| Schedule Class C downlink packet
10:33:19:762|INFO| GW:00-80-00-00-00-00-aa-85|FRAME-TX|IP: 127.0.0.1:53760 CH: LC6 DEV: 00-6a-ff-cd FCNT: 00000009 REPEAT: 0
10:33:19:769|INFO| ED:00-04-a3-0b-00-1e-a5-a0|SCHED-TX|Q-SIZE: 1 PKT-ROOM: 51
10:33:19:770|DEBUG| getTimeOnAirMs SF: 12 BW: 125 PL: 8 SZ: 37 TOA: 1810
10:33:19:770|DEBUG| ED:00-04-a3-0b-00-1e-a5-a0|PACKET-TX|ADDR: 006affcd PORT: 81 ACK: 0 FCNT: 00000009
10:33:19:771|DEBUG| GW:00-80-00-00-00-00-aa-85|FRAME-TX|DATA: 60cdff6a0000090051dfae52bfc0538a48b179828d977989b916ad22696a76d47385b11d3fc30a00fc
10:33:19:772|DEBUG| GW:00-80-00-00-00-00-aa-85|PACKET-TX|RX2 OFFSET: 7000000
10:33:19:786|DEBUG| GW:00-80-00-00-00-00-aa-85|FRAME-TX|JSON: {“txpk”:{“appeui”:”54-45-4c-4c-49-4e-4b-00″,”codr”:”4/5″,”data”:”YM3/agAACQBR365Sv8BTikixeYKNl3mJuRatImlqdtRzhbEdP8MKAPw=”,”datr”:”SF12BW125″,”deveui”:”00-04-a3-0b-00-1e-a5-a0″,”freq”:869.52499999999998,”gweui”:”00-80-00-00-00-00-aa-85″,”imme”:true,”ipol”:true,”modu”:”LORA”,”ncrc”:true,”powe”:0,”rfch”:0,”size”:41,”twnd”:2}}
10:33:19:787|DEBUG| GW:00-80-00-00-00-00-aa-85|DUTY-CYCLE|BAND: 2 DUTY: 360000
10:33:19:787|DEBUG| getTimeOnAirMs SF: 12 BW: 0 PL: 8 SZ: 41 TOA: 2138
10:33:19:788|INFO| Update DC Band: 2 Duration: 2138 time-on-air available: 357862 ms
10:33:19:788|INFO| GW:00-80-00-00-00-00-aa-85|UDP-TX|JSON-SIZE:326
10:33:19:789|TRACE| TX-MSG|127.0.0.1:53760 330 bytes
10:33:19:807|DEBUG| DeviceTransmitController::TransmitFrame ID: 66
10:33:21:984|TRACE| TX-ACK|127.0.0.1:53760 4 bytes 01948104
10:33:21:985|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:53760
10:33:32:185|TRACE| TX-ACK|127.0.0.1:53760 4 bytes 0103d504
10:33:32:186|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:53760

Message from the manually created node:

10:33:40:908|DEBUG| ED:00-11-22-33-44-55-66-77|DOWNLINK|Queue {“data”:”IFJTU0k6LTgwICBTTlI6IDkuMiAgQ0g6IDUgBQ==”,”ack”:false,”port”:81}
10:33:40:924|WARNING| ED:00-11-22-33-44-55-66-77|QUEUE|Created downlink record ID:67
10:33:40:924|INFO| ED:00-11-22-33-44-55-66-77|QUEUE-TX|DATA SIZE: 28
10:33:42:384|TRACE| TX-ACK|127.0.0.1:53760 4 bytes 01692504
10:33:42:385|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:53760
10:33:52:584|TRACE| TX-ACK|127.0.0.1:53760 4 bytes 01481004
10:33:52:585|TRACE| GW:00-80-00-00-00-00-aa-85|SEEN|PULL-DATA|127.0.0.1:53760

This message does not progress, but I do not know why.

[Antonio Muñoz]

Thanks Jason.
I’ll try.
regards

[Antonio Muñoz]

Hi
I have this problem too.
The received packets stop arriving at the node-RED application, and the solution I have taken is to restart the conduit when a certain time passes without the node-RED app receiving any packet.
It happens to me with the previous version (1.4.3), and I thought it had been fixed in version 1.4.14.
This does not happen very often, but it should never happen.

Regards.

[Antonio Muñoz]

Hello
I am also interested in this.
Currently I use a slot for lora and another for the serial port.
If I could use a USB 2 serial port, I would use two lora cards.
It’s possible ?
Can I use a standard usb-serial converter?

Thank you.

[Antonio Muñoz]

Thank you very much for your quick response.
All an example of effectiveness.
very good

[Antonio Muñoz]

Thank you very much for your quick response.
All an example of effectiveness.
very good

[Antonio Muñoz]

Hello Jason again.
the commands work very well, but now I do not know how to restart the lora-network-server without restarting the conduit for the changes to take effect.
If I modify the parameters through the setup of the conduit, the lora-network-server is restarted and loads its parameters, but if I do it with the commands through the api, I can save, but they do not load.

Thank you.

[Antonio Muñoz]

Thank you, Jason.
I’m working with class A, and the idea is that the end devices are programmed with the Rx2frecuency depending on the conduit they connect to, with which I understand that this information is not necessary to send it from the conduit to the end devices. Is this correct?
I will try with the information you have given me.
Thank you very much again.
Regards

[Antonio Muñoz]

Thanks Jason.
I will be very useful to use the apis. I currently have a project in which I must use up to 10 conduits, and I think there may be a problem if all the conduits use the same Rx2frequency. In any case it would be better to be able to choose the working Rx2frequency. Is it not possible in any way?

Thanks again

[Antonio Muñoz]

thankyou very match

[Antonio Muñoz]

This is the program code:

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <pthread.h>

unsigned short c_timer;

void *thread_function(void *arg)

{

while(c_timer)

{

sleep(1);

c_timer–;

}

return NULL;

}

int main (void)

{

pthread_t mythread;

c_timer = 20;

if ( pthread_create( &mythread, NULL, thread_function, NULL) )

{

printf(“Error.”);

abort();

}

printf(“20 sec. for exit”);

while(c_timer);

printf(“Goodbye”);

}

to build:

– source env-oe.sh

– export PATH=${OETREE}/build/tmp/sysroots/i686-linux/usr/armv5te/bin:$PATH

– arm-corecdp-linux-gnueabi-gcc -o test test.c

This is the result of the build:

/tmp/cc5EYUVc.o: In function `main’:

test.c:(.text+0x8c): undefined reference to `pthread_create’

collect2: ld returned 1 exit status

Thanks

[Antonio Muñoz]

I am comming to use the mtcdp.

I am tryng to build a litle program with the funtion pthread_create, but the compiler (or linker) dont match the funtion. In the include file (pthread.h) is declared as external.

I have buil a hello world program with no problem.

I am using the mtcdp_2.0.2 version.

Thanks

[Author]

Posts