Chirpstack v4 with Device DR5 SF7 (rssi -75) Region EU868 (Min DR: 0, max DR: 5)
I try a downlinks longer than 51 characters and get ERROR:
level:"ERROR"
code:"DOWNLINK_PAYLOAD_SIZE"
description:"Device queue-item discarded because it exceeds the max. payload size"
max_payload_size:"51"
item_size:"71"
queue_item_id:"54963022-xxxx-4x85-xxxxxxxxxxxxxxxx"
Is there somewhere else to specify the max DR (like in the service profile in V3) to create my downlink?
This say the maximum payload is 51 for some regions when you use DataRate index 0,1,2
I think the code follow that logic:
/// Returns the max-payload size for the given data-rate index, protocol version
/// and regional-parameters revision.
/// When the version or revision is unknown, it will return the most recent
/// implemented revision values.
fn get_max_payload_size(
Thanks for the answer. I don’t see a solution for my use case. Using a downlink >51 bytes works “out of the box” in TTN. In Chirpstack v3, the working way was: BEFORE creating the device, enter a “Service Profile” with “max DR 5” and assign it to the new device. With this setting, a downlink >51 bytes also worked here.
As mentioned above, the device is associated with a data rate index of 5, so a maximum size of 222 bytes should be valid for the EU863-870 region.
Is it perhaps not yet implemented in v4, or is there a setting option?
Could you share a screenshot of one of the last uplinks of the device from the frame logs?
Yes, thank you, for taking the time to look at it. I will try to recreate any constellations and share the results.
{"deduplicationId":"05151faa-f4b0-4d1e-9099-a4fa355b8d0f","time":"2022-10-20T07:06:06.406573+00:00","deviceInfo":{"tenantId":"52f14cd4-c6f1-4fbd-8f87-4025e1d49242","tenantName":"ChirpStack","applicationId":"01a72130-20ef-4883-a29c-c25cf3f7b338","applicationName":"Lobaro_Modbus_Hybrid","deviceProfileId":"13506518-c026-431a-b1f8-51eec62ab43f","deviceProfileName":"Lobaro Hybrid Modbus","deviceName":"Lobaro_Modbus_Hybrid ","devEui":"70b3d5e050013952"},"devAddr":"01cbee78","adr":true,"dr":5,"fCnt":5,"fPort":20,"data":"AA3XAloAtAMvAKMBgA==","rxInfo":[{"gatewayId":"50313953530a4750","uplinkId":769,"time":"2022-10-20T07:06:06.406573+00:00","rssi":-65,"snr":9.0,"channel":4,"location":{"latitude":53.554825529205644,"longitude":9.921496510505678},"context":"mHKWdA==","metadata":{"region_name":"eu868","region_common_name":"EU868"}}],"txInfo":{"frequency":867300000,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":7,"codeRate":"CR_4_5"}}}}
I am running into a similar situation in the US915 region. My message size is 73 bytes. I just figured out that messages were not being sent due to size in v4, so I need to refresh myself on max sizes for different DR values.
This was also working in v3 for me.
From logs:
WARN chirpstack::downlink::data: Device queue-item discarded because of max. payload size dev_eui=...
My DR is reported as 3 in the UI. According to the Semtech link posted above, I should be able to send at least 115 bytes (max safe size), and ideally 242 bytes according to the US table.
I can send fairly large uplink messages, routinely 160-170 bytes.
For some reason I cannot upload the up message screen grab, but the info is:
Down message:
Update: I was able to grab the integration LogEvent that is generated when this happens. The relevant data is:
description="Device queue-item discarded because it exceeds the max. payload size" dev_eui=... device_name=... item_size=73 log_code=1 log_level=2 max_payload_size=53 queue_item_id=...
It looks like the DR1 max size is being used (according to the Semtech link above), even though this device is DR3. I have been looking through the code and I don’t see any obvious reason the lower size would be used. I’m not very proficient in Rust, though.
For EU868 I’ve not been able to reproduce this issue (yet). I will try to reproduce for US915. Could you share the LoRaWAN mac version and Regional Parameter revision settings from the device-profile?
MAC version: 1.0.2
Regional params: currently RP002-1.0.2 but I’ve tried a few different ones
I started setting up a rust debug build to step through, but I have become side-tracked with other priorities.
@brocaar any update on this? What is the best way for me to debug this locally, given I don’t have a rust development environment set up. I am familiar with gdb, so I can use that instead of a full blown development environment. I will explore that later this week.
Have you tried to reproduce this issue with the latest ChirpStack version? There was a downlink related bugfix in one of the latest bugfix releases.
I just tried it with the 4.1.0 release. It is still refusing to send the downlink message due to size. I have message sizes ranging in the 60 < x < 80 byte range. I have trace logging enabled, so here are some relevant log messages.
When I eliminate some of the data in the response, cutting the messages down to around 36 bytes, it is delivered.
Let me know what I can do to help track this down.
2022-12-06T22:05:47.447288Z TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
2022-12-06T22:05:47.447379Z TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
2022-12-06T22:05:47.451927Z TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=1
2022-12-06T22:05:47.452074Z TRACE schedule{dev_eui=000......}: chirpstack::downlink::data: Handle schedule next-queue item flow
2022-12-06T22:05:47.455943Z TRACE schedule{dev_eui=000......}: chirpstack::downlink::data: Selecting downlink gateway
2022-12-06T22:05:47.455981Z TRACE schedule{dev_eui=000......}: chirpstack::downlink::data: Getting Class-C device lock
2022-12-06T22:05:47.456089Z INFO chirpstack::storage::device: Aquiring device lock dev_eui=000......
2022-12-06T22:05:47.456671Z TRACE schedule{dev_eui=000......}: chirpstack::downlink::data: Setting immediately flag
2022-12-06T22:05:47.456713Z TRACE schedule{dev_eui=000......}: chirpstack::downlink::data: Setting tx-info for RX2
2022-12-06T22:05:47.457421Z TRACE schedule{dev_eui=000......}: chirpstack::downlink::data: Getting next device queue-item
2022-12-06T22:05:47.462091Z INFO schedule{dev_eui=000......}: chirpstack::storage::device_queue: Device queue-item deleted id=04c614ae-8e0e-40a8-81ce-274dd70495a8
2022-12-06T22:05:47.463374Z TRACE schedule{dev_eui=000......}: chirpstack::integration::gcp_pub_sub: Initializing GCP Pub-Sub integration
2022-12-06T22:05:47.464952Z INFO schedule{dev_eui=000......}: chirpstack::integration::gcp_pub_sub: Publishing event event=log dev_eui=000......
2022-12-06T22:05:47.466046Z INFO schedule{dev_eui=000......}: chirpstack::integration::mqtt: Publishing event topic=application/d4db8afe-64a9-450f-aa0c-ce4575d14661/device/000....../event/log
2022-12-06T22:05:47.529670Z WARN schedule{dev_eui=000......}: chirpstack::downlink::data: Device queue-item discarded because of max. payload size dev_eui=000...... device_queue_item_id=04c614ae-8e0e-40a8-81ce-274dd70495a8
2022-12-06T22:05:47.531671Z TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
After an update, the downlinks work as expected. Now nothing stands in the way of moving to v4. Thanks.
Thanks for re-testing an confirming that it works fine now 
I am still seeing downlink data discarded due to size in the US915 bands. I have double confirmed I am running the 4.1.0 release. What is the specific change that might have had an effect on this behavior?
If it makes a difference, I am using a device based on the Microchip RN2903 module.
I have a little more information from the chirpstack logs. It looks like the server is frequently updating the device configuration. Here is an example data_up event. Note the data rate being updated to dr=4, although I always see it reported as 3, and the requested channel reconfiguration.
I have read the Regional Parameters spec as it pertains to the US bands, especially the section on the LinkAdrReq command, but it’s not clear to me what is going on in the server.
2022-12-09T23:40:29.675151Z INFO chirpstack::storage::device: Setting device lock dev_eui=000.......
2022-12-09T23:40:29.675898Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Setting scheduler_run_after for device
2022-12-09T23:40:29.678999Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Filtering rx_info by tenant_id
2022-12-09T23:40:29.679056Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Decrypting mac-commands
2022-12-09T23:40:29.679101Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Decrypting FRMPayload
2022-12-09T23:40:29.679153Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Logging uplink frame-set
2022-12-09T23:40:29.680145Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Set ADR flag in device-session
2022-12-09T23:40:29.680168Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Set uplink data-rate and reset tx-power on change
2022-12-09T23:40:29.683363Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::storage::device: Data-rate updated dev_eui=000....... dr=4
2022-12-09T23:40:29.683410Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Set Class-B beacon locked
2022-12-09T23:40:29.683425Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Logging uplink meta
2022-12-09T23:40:29.684391Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Handling uplink mac-commands
2022-12-09T23:40:29.684518Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Mac-commands in f_opts
2022-12-09T23:40:29.689593Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::storage::mac_command: Pending mac-command block deleted dev_eui=000....... cid=LinkADRAns
2022-12-09T23:40:29.690810Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::maccommand::link_adr: LinkADRReq acknowledged dev_eui=000....... tx_power_index=3 dr=3 nb_trans=1 enabled_channels=[8, 9, 10, 11, 12, 13, 14, 15, 65]
2022-12-09T23:40:29.691921Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Saving gateway rx-info for device
2022-12-09T23:40:29.692376Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::storage::device_gateway: Gateway rx-info saved dev_eui=000.......
2022-12-09T23:40:29.692404Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Sending uplink event
2022-12-09T23:40:29.694125Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::integration::gcp_pub_sub: Initializing GCP Pub-Sub integration
2022-12-09T23:40:29.695792Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::integration::gcp_pub_sub: Publishing event event=up dev_eui=000.......
2022-12-09T23:40:29.697213Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::integration::mqtt: Publishing event topic=application/d4db8afe-64a9-450f-aa0c-ce4575d14661/device/000......./event/up
2022-12-09T23:40:29.754896Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Detecing and saving measurements
2022-12-09T23:40:29.754942Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Syncing uplink frame-counter
2022-12-09T23:40:29.754950Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Setting region_name to device-session
2022-12-09T23:40:29.754964Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Saving device-session
2022-12-09T23:40:29.756266Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::storage::device_session: Device-session saved dev_eui=000....... dev_addr=0048be2a
2022-12-09T23:40:29.756338Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Saving device metrics
2022-12-09T23:40:29.756762Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::storage::metrics: Metrics saved name=device:000....... aggregation=HOUR
2022-12-09T23:40:29.757258Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::storage::metrics: Metrics saved name=device:000....... aggregation=DAY
2022-12-09T23:40:29.757828Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::storage::metrics: Metrics saved name=device:000....... aggregation=MONTH
2022-12-09T23:40:29.757858Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up: chirpstack::uplink::data: Starting downlink data flow
2022-12-09T23:40:29.757919Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Downlink response flow
2022-12-09T23:40:29.757944Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Selecting downlink gateway
2022-12-09T23:40:29.758046Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Setting tx-info for RX1
2022-12-09T23:40:29.758320Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Setting tx-info for RX2
2022-12-09T23:40:29.758373Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Getting next device queue-item
2022-12-09T23:40:29.760051Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Requesting custom channel re-configuration
2022-12-09T23:40:29.760083Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Requesting channel-mask reconfiguration
2022-12-09T23:40:29.760111Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Requesting ADR change
2022-12-09T23:40:29.762066Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::storage::mac_command: Pending mac-command block set dev_eui=000....... cid=LinkADRReq
2022-12-09T23:40:29.762150Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Requesting device-status
2022-12-09T23:40:29.762197Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Requesting rejoin param setup
2022-12-09T23:40:29.762248Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Setting ping-slot parameters
2022-12-09T23:40:29.762289Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Setting rx parameters
2022-12-09T23:40:29.762328Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Setting tx parameters
2022-12-09T23:40:29.762386Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Setting downlink PHYPayloads
2022-12-09T23:40:29.762560Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Updating device queue-item
2022-12-09T23:40:29.762602Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Saving downlink frame
2022-12-09T23:40:29.763276Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::storage::downlink_frame: Downlink-frame saved downlink_id=678629962
2022-12-09T23:40:29.763367Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Saving device-session
2022-12-09T23:40:29.763850Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::storage::device_session: Device-session saved dev_eui=000....... dev_addr=0048be2a
2022-12-09T23:40:29.763910Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::downlink::data: Sending downlink frame
2022-12-09T23:40:29.764016Z INFO up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::gateway::backend::mqtt: Sending downlink frame gateway_id=0016c001ff19cf16 topic=us915_1/gateway/0016c001ff19cf16/command/down json=false
2022-12-09T23:40:29.764537Z TRACE up{deduplication_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}:data_up:data_down{downlink_id=4078b24a-f7b8-4378-8355-12dee18fd7c6}: chirpstack::gateway::backend::mqtt: Message sent
Followed by the downlink message attempt…
2022-12-09T23:40:35.123881Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Handle schedule next-queue item flow
2022-12-09T23:40:35.127182Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Selecting downlink gateway
2022-12-09T23:40:35.127239Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Getting Class-C device lock
2022-12-09T23:40:35.127296Z INFO chirpstack::storage::device: Aquiring device lock dev_eui=000.......
2022-12-09T23:40:35.127556Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Setting immediately flag
2022-12-09T23:40:35.127586Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Setting tx-info for RX2
2022-12-09T23:40:35.127634Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Getting next device queue-item
2022-12-09T23:40:35.130341Z INFO schedule{dev_eui=000.......}: chirpstack::storage::device_queue: Device queue-item deleted id=5ab2a54b-64a1-47a0-b3be-9f1e30970ea6
2022-12-09T23:40:35.131571Z TRACE schedule{dev_eui=000.......}: chirpstack::integration::gcp_pub_sub: Initializing GCP Pub-Sub integration
2022-12-09T23:40:35.133032Z INFO schedule{dev_eui=000.......}: chirpstack::integration::gcp_pub_sub: Publishing event event=log dev_eui=000.......
2022-12-09T23:40:35.134462Z INFO schedule{dev_eui=000.......}: chirpstack::integration::mqtt: Publishing event topic=application/d4db8afe-64a9-450f-aa0c-ce4575d14661/device/000......./event/log
2022-12-09T23:40:35.199052Z WARN schedule{dev_eui=000.......}: chirpstack::downlink::data: Device queue-item discarded because of max. payload size dev_eui=000....... device_queue_item_id=5ab2a54b-64a1-47a0-b3be-9f1e30970ea6
2022-12-09T23:40:35.201257Z TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
I am also seeing all channels being turned off at times, resulting in no data being sent and (re)join failing. I have more data on that, but I’ll send that in another post if it would help. This does not happen on some other devices that send smaller data payloads less frequently.
Knowing the change that fixed this for EU868 might enable me to dig in some more.
Thanks.
Please note that you are sharing two downlinks. One is for Class-A downlink. The other for Class-C. Is this intentional?
I don’t understand. I pulled out the log messages based on one dev_eui and one deduplication_id value, which is a Class-C device. Maybe I am not understand what I am seeing in the logs.
I am seeking to understand the mechanism that is causing the max payload size to be reduced. This was not an issue in v3. The hurdles to running Chripstack v4 services in a debugger myself are higher than in v3, as I am not set up to debug Rust. However, I am willing to do it if I have more of an idea where to look.
2022-12-09T23:40:35.123881Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Handle schedule next-queue item flow
2022-12-09T23:40:35.127182Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Selecting downlink gateway
2022-12-09T23:40:35.127239Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Getting Class-C device lock
2022-12-09T23:40:35.127296Z INFO chirpstack::storage::device: Aquiring device lock dev_eui=000.......
2022-12-09T23:40:35.127556Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Setting immediately flag
2022-12-09T23:40:35.127586Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Setting tx-info for RX2
2022-12-09T23:40:35.127634Z TRACE schedule{dev_eui=000.......}: chirpstack::downlink::data: Getting next device queue-item
2022-12-09T23:40:35.130341Z INFO schedule{dev_eui=000.......}: chirpstack::storage::device_queue: Device queue-item deleted id=5ab2a54b-64a1-47a0-b3be-9f1e30970ea6
2022-12-09T23:40:35.131571Z TRACE schedule{dev_eui=000.......}: chirpstack::integration::gcp_pub_sub: Initializing GCP Pub-Sub integration
2022-12-09T23:40:35.133032Z INFO schedule{dev_eui=000.......}: chirpstack::integration::gcp_pub_sub: Publishing event event=log dev_eui=000.......
2022-12-09T23:40:35.134462Z INFO schedule{dev_eui=000.......}: chirpstack::integration::mqtt: Publishing event topic=application/d4db8afe-64a9-450f-aa0c-ce4575d14661/device/000......./event/log
2022-12-09T23:40:35.199052Z WARN schedule{dev_eui=000.......}: chirpstack::downlink::data: Device queue-item discarded because of max. payload size dev_eui=000....... device_queue_item_id=5ab2a54b-64a1-47a0-b3be-9f1e30970ea6
2022-12-09T23:40:35.201257Z TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
These logs relate to a Class-C downlink. Some indicators:
Right, so the issue is:
Device queue-item discarded because of max. payload size dev_eui=000.......
and I don’t understand why. The message size is in the 60 < x < 80 bytes, DR is 3.
adr:true
dr:3
fCnt:7
fPort:101
confirmed:true
This was not an issue I experienced with v3, and I am trying to understand what is different.
Doug
Hi,
I just upgraded to Chirpstack 4.2.0, and I am still seeing what looks to me to be an incorrect data rate applied to my download payload size. The events page now shows the error message:
level:"ERROR"
code:"DOWNLINK_PAYLOAD_SIZE"
description:"Device queue-item discarded because it exceeds the max. payload size"
max_payload_size:"53"
item_size:"67"
queue_item_id:"76c48f7f-a741-448d-aff3-b4a84018c3cd"
The max_payload_size:"53" indicates this message is being treated as a DataRate=1 message, according to the Regional Parameters documentation.
The Chirpstack UI and an uplink message just prior to the downlink attempt report:
This is a class C device.
@brocaar I can appreciate you are prioritizing users who have sponsored the project. That is not possible for me right now. I am completely willing to further debug this issue myself, so any pointers you can provide would help. I have contributed pull requests in the past. I want to make sure this is not my problem before I create an issue.
Thanks.
Hi dreese,
I just wanted to let you know that I am currently experiencing the same issue as you. I’m working with a dr of 5 for EU863 where I should be able to send payloads of up to 222 bytes but I’m getting the same error as you max_payload_size:“53”.
I’m also working on Chirpstack 4.2.0. I don’t know what to do anymore to fix this.